RE: [Xen-devel] RE: [Patch] Fix IDLE issue with sedf scheduler on IA64

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

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