Bug 523931 - [sched-sedf]The ID of the domain is negative.
Summary: [sched-sedf]The ID of the domain is negative.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen
Version: 5.4
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Xen Maintainance List
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 514498
TreeView+ depends on / blocked
 
Reported: 2009-09-17 09:13 UTC by Rita Wu
Modified: 2013-07-03 01:33 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-03-15 10:55:53 UTC


Attachments (Terms of Use)

Description Rita Wu 2009-09-17 09:13:33 UTC
Description of problem:
The ID of the domain is "-1".

Version-Release number of selected component (if applicable):
kmod-gnbd-xen-0.1.5-2.el5
xen-libs-3.0.3-94.el5
xen-debuginfo-3.0.3-94.el5
kernel-xen-2.6.18-164.el5
xen-3.0.3-94.el5
kernel-xen-devel-2.6.18-164.el5
kmod-gfs-xen-0.1.34-2.el5


How reproducible:
always

Steps to Reproduce:
1.# xm sched-sedf domainname (I used the domain based on rhel5.4)


  
Actual results:
The ID is "-1" (negative).

Expected results:

The ID should be plus.
Additional info:

Comment 1 Rita Wu 2009-09-17 09:45:24 UTC
And all the domain's ID is "-1":
]# xm sched-sedf 
Name                              ID Period(ms) Slice(ms) Lat(ms) Extra Weight
Domain-0                          -1      -0.0      -0.0    -0.0     -1     -1
rhel5u4_fv_x86_64                 -1      -0.0      -0.0    -0.0     -1     -1

Comment 2 Chris Lalancette 2009-09-17 10:01:29 UTC
(In reply to comment #1)
> And all the domain's ID is "-1":
> ]# xm sched-sedf 
> Name                              ID Period(ms) Slice(ms) Lat(ms) Extra Weight
> Domain-0                          -1      -0.0      -0.0    -0.0     -1     -1
> rhel5u4_fv_x86_64                 -1      -0.0      -0.0    -0.0     -1     -1  

While this behavior is undesirable, are you actually using the sedf scheduler?  You'd have to have explicitly configured it when booting, and it also does scheduling of SMP guests (including dom0) very poorly.

Chris Lalancette

Comment 3 Rita Wu 2009-09-18 06:07:51 UTC
Chris
Here is the settings of my grub.conf
title Red Hat Enterprise Linux Server (2.6.18-164.el5xen)
        root (hd0,0)
        kernel /boot/xen.gz-2.6.18-164.el5 sched=sedf
        module /boot/vmlinuz-2.6.18-164.el5xen ro root=LABEL=/ rhgb quiet 
        module /boot/initrd-2.6.18-164.el5xen.img 
And the result is the same with comment #1

Comment 4 Chris Lalancette 2009-09-18 06:15:36 UTC
(In reply to comment #3)
> Chris
> Here is the settings of my grub.conf
> title Red Hat Enterprise Linux Server (2.6.18-164.el5xen)
>         root (hd0,0)
>         kernel /boot/xen.gz-2.6.18-164.el5 sched=sedf
>         module /boot/vmlinuz-2.6.18-164.el5xen ro root=LABEL=/ rhgb quiet 
>         module /boot/initrd-2.6.18-164.el5xen.img 
> And the result is the same with comment #1  

OK, interesting.  Why are you using the sedf scheduler, then?  Is there something you can't accomplish with the credit (default) scheduler?

(note that this doesn't mean I don't think it's a bug, just that hardly anyone uses sedf and thus the bugs against it are generally low-priority)

Chris Lalancette

Comment 5 Rita Wu 2009-09-18 06:35:18 UTC
Hi Chris
For the simple reason that I have to create test plan for xen now.

BTW: it seems the function of setting edf parameters by sched-sedf doesn't work.( xm sched-sedf domainid -p 20 -s 0 -l 1 -e 0 -w 10
) 
Is that another bug?Thanks.

Rita

Comment 6 Chris Lalancette 2009-09-18 06:42:07 UTC
(In reply to comment #5)
> Hi Chris
> For the simple reason that I have to create test plan for xen now.

Ah, OK.  Makes sense.  As I mentioned above, the SEDF scheduler isn't super useful, so it's not worth spending a lot of time on.  But at least simple things should work :).

> 
> BTW: it seems the function of setting edf parameters by sched-sedf doesn't
> work.( xm sched-sedf domainid -p 20 -s 0 -l 1 -e 0 -w 10
> ) 
> Is that another bug?Thanks.

Yeah, probably.  Nobody has used this code in quite a long time, so it's probably bit-rotted.  We'll keep track of it, but it's going to be low-priority.

Chris Lalancette

Comment 9 Michal Novotny 2011-03-02 12:57:49 UTC
Well, I've added some extra debugging to the xm/main.py and it's not supported for the domain I've used to test.

# xm sched-sedf rhel5-64fv
Name                              ID Period(ms) Slice(ms) Lat(ms) Extra Weight
debug: <Fault 2: "(22, 'Invalid argument')">
debug: {}
debug: {'latency': -1, 'slice': -1, 'name': 'rhel5-64fv', 'weight': -1, 'period': -1, 'domid': -1, 'extratime': -1}
rhel5-64fv                        -1      -0.0      -0.0    -0.0     -1     -1

Those lines starting by "debug:" were those that I've added for the debugging purposes so this is not supported to get the SEDF information. The fault is coming from the server.xend.domain.cpu_sedf_get() and the exception type is xmlrpclib.Fault.

This is calling the domain_cpu_sedf_get() method from tools/python/xen/xend/XendDomain.py of the user-space stack.

I'll investigate this further.
Michal

Comment 10 Michal Novotny 2011-03-02 13:35:38 UTC
This is being called from the the Python code that's calling the xc_sedf_domain_get() function of the libxc. The libxc code is implemented in the tools/libxc/xc_sedf.c where the XEN_DOMCTL_scheduler_op and XEN_DOMCTL_SCHEDOP_getinfo hypercall with settings of scheduler to SEDF is being placed.

The issue is caused by xend/XendDomain.py's call to xc.sedf_domain_get() method since this returns the exception. Therefore the parsing of sedf information in the xm returns -1 values to almost everything. The error value is coming from the hypervisor and since the return value is non-zero it fails to get the information and go on with the user-space code.

According to the hypervisor code the XEN_DOMCTL_scheduler_op hypercall is basically returning the value of sched_adjust() hypervisor function call. It seems like that it's failing there with -EINVAL because of p->vcpu[0] seems to be NULL (common/sched_sedf.c:1417) so this is most likely kernel-xen issue.

Michal

Comment 12 Miroslav Rezanina 2011-03-15 10:55:53 UTC
As sedf scheduler is not working on hypervisor/kernel level xend can't get correct values. No customer has reported this issue yet so noone is probably interested in it - we won't fix this issue. Closing.


Note You need to log in before you can comment on or make changes to this bug.