[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] IDLE domain is scheduled more than dom0


  • To: "Stephan Diestelhorst" <sd386@xxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Fri, 8 Jul 2005 17:44:00 +0800
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 08 Jul 2005 09:42:54 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcWDoZFKM8wHHwheSkamindKyBwiFw==
  • Thread-topic: IDLE domain is scheduled more than dom0

Hi, Stephan,
        Latest hg tree has set your sEDF scheduler as default, and then
I saw some strange behavior as mentioned in subject on XEN/IA64. The
source tree is based on xen-ia64-unstable.hg set up by Dan, which was
just newly created yesterday and had default scheduler change as above
too.

        An example is: (No DomU created)
                      Total cpu time
IDLE                   93def9294f
Dom0                  5420288a1b

        Shouldn't IDLE domain not be scheduled for most time? Because
idle task will call into PAL for power save on XEN/IA64, the performance
is really, really bad to boot Dom0. The net effect is about ten times
slower. After adding "sched=bvt", everything back to normal.

        I'm not sure whether same problem also exists on x86, maybe not
that obvious. Is there any special sEDF parameter setting to be done
arch specific...?

        For previous BVT scheduler, the evt (effective virtual time) for
IDLE task is set as -1, which has ideal effect to always schedule Dom0
as long as it's runable. IDLE domain should never be scheduled after
Dom0 is up, unless explicit sleep request issued from Dom0.

        However after looking into sEDF code, it seems that current
running ED is very likely to be moved into wait queue after a period,
while IDLE is always on run queue. Then regarding case with only Dom0
and IDLE, IDLE will be scheduled more frequently than expected, even
when dom0 doesn't request to sleep explicitly. When multiple domains
exist, that phenomenon is instead not that obvious, since domains will
gear to run queue alternatively and prevent IDLE to be scheduled.

        So maybe some special consideration should be added to IDLE
domain...  I'm actually a stranger to this new scheduler, and please
correct me if I throw water on incorrect direction. ;-)

Thanks,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.