|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] RE: [Patch] Fix IDLE issue with sedf scheduler on IA64
Keir> An idle domain is a convenient abstraction for thinking about the Keir> current scheduling state of a cpu -- it allows us to treat things more Keir> uniformly in the common code. Of course we can treat the idle domains Keir> very specially during state switch for performance. So... an idle domain is a convenient abstraction which, it seems, results in every platform inconveniently adding code to work around the abstraction? ;-) Isn't it really the case that an idle domain/process is an anachronistic concept that pre-dates "low power states" and is used by Xen mostly because Xen is leveraging OS scheduler designs (that also pre-date low power states)? I recognize that that's still a perfectly reasonable design choice for Xen... just trying to ensure I understand. Ian> >You misunderstood my suggestion. We would still switch to the idle Ian> >domain, we just load the dom0 bulk state such that the lazy switch Ian> logic Ian> >won't won't have to do anything should dom0 be the next Ian> domain to run. Kevin> Then, I fully agree! ;-) The non-lazy state on ia64 is still significant but I agree this reduces the issue to a level its probably not worth worrying about any more. One additional question however: Is there a way to determine/query "am I (current) the only domain on the run queue (other than idle)?"**. If so, I can leave the processor fully in "domain0 context" (and leave domain0 runnable) when I enter a low power state, thus eliminating the non-lazy state switch and reducing the interrupt latency when all domains are (virtual-) I/O bound. Dan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |