WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Re: IDLE domain is scheduled more than dom0
From: Stephan Diestelhorst <sd386@xxxxxxxxxxxx>
Date: Mon, 11 Jul 2005 13:59:44 +0100
Delivery-date: Mon, 11 Jul 2005 12:58:33 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <571ACEFD467F7749BC50E0A98C17CDD807420543@pdsmsx403>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <571ACEFD467F7749BC50E0A98C17CDD807420543@pdsmsx403>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.6.2
> >From: sd386@xxxxxxxxxxxxxxxx [mailto:sd386@xxxxxxxxxxxxxxxx] On
> >Behalf Of Stephan Diestelhorst
> >Sent: Friday, July 08, 2005 11:15 PM
> >
> >>  An example is: (No DomU created)
> >>                       Total cpu time
> >> IDLE                   93def9294f
> >> Dom0                  5420288a1b
> >
> >Hi Kevin,
> >  this is quite an interesting result.
> >In "sedf_add_task" dom0 is set to 15ms every 20ms, so this means that
>
> it gets
>
> >75% of the cpu_time. During boottime this might vary due to lots of I/O
>
> but a
>
> >ratio of 33% for dom0 and 66% for the idle task is strange. Could you
>
> please
>
> >try two things:
> >a) give the domain extratime by modfying the line
> >inf->stauts = EXTRA_NONE | SEDF_ASLEEP;
> >to
> >inf->status = EXTRA_AWARE | SEDF_ASLEEP;
> >in "sedf_add_task" "case 0" in sched_sedf.c
>
> This can't help, with almost same statistics:
>                           Total cpu time
> IDLE                      19CE88F3E7
> Dom0                     1040A91728
>
> Not sure whether that strange coming from the fact that IDLE is also
> initialized with period as WEIGHT_PERIOD(100ms)?
This will not matter, and in fact add_domain will not get called for the idle 
task. 
> >b) set inf->slice = MILLIESECS(20);
>
> Instead this approach has exactly same effect as previous bvt:
>                           Total cpu time
> IDLE                      48FD92BF
> Dom0                     2D61AF8D5D
>
> Then IDLE wasn't scheduled any more after Dom0 is up, except explicit
> request. Though Dom0 is placed on waitq when in the start of
> do_schedule, it will be moved back to runq when update_queues. The
> reason is that the start of next period of Dom0 is always earlier than
> NOW(), when inf->slice == inf->period. Then scheduler is always happy to
> choose Dom0 instead of IDLE, since both in runq.

Okay, thanks for your investigation!
The thing is that the idle domain IS the lowest prioritised domain in the 
system! So if you set the EXTRA_AWARE flag, it should almost never get 
scheduled. The only case when this will happen is when dom0 does I/O, as this 
is treated differently whether it occurs in EDF-time or in extra-time. I will 
have a closer look at this, as this behaviuor is not acceptable. 

> So, to make b) change can give smooth boot for Dom0, but not sure
> whether this will affect multiple domains since your intent is to set
> Dom0 as 75% threshold. Then how about adding a special check in
> update_queues, upon the case where IDLE is only candidate on runq? In
> that case, it's better to pull one from waitq which is run-able there
> only being slice consumed up, to begin a new round immediately...
This is exactly what happens if you set the extra-flag!

As I said, I will have a closer look on what happens with I/O during 
extratime.

Thanks for your efforts!

Stephan

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