xen-devel
[Xen-devel] Re: IDLE domain is scheduled more than dom0
> >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
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- RE: [Xen-devel] Re: IDLE domain is scheduled more than dom0, Magenheimer, Dan (HP Labs Fort Collins)
- RE: [Xen-devel] Re: IDLE domain is scheduled more than dom0, Magenheimer, Dan (HP Labs Fort Collins)
- RE: [Xen-devel] Re: IDLE domain is scheduled more than dom0, Ian Pratt
- [Xen-devel] RE: IDLE domain is scheduled more than dom0, Tian, Kevin
- [Xen-devel] Re: IDLE domain is scheduled more than dom0,
Stephan Diestelhorst <=
- [Xen-devel] RE: IDLE domain is scheduled more than dom0, Tian, Kevin
- RE: [Xen-devel] Re: IDLE domain is scheduled more than dom0, Tian, Kevin
- RE: [Xen-devel] Re: IDLE domain is scheduled more than dom0, Tian, Kevin
|
|
|