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/
Home Products Support Community News


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

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>, "Hollis Blanchard" <hollisb@xxxxxxxxxx>
Subject: RE: [Xen-devel] RE: [Patch] Fix IDLE issue with sedf scheduler on IA64
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Thu, 14 Jul 2005 07:48:14 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 14 Jul 2005 14:46:58 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcWHt6n1Iv/xXgGKT1SJ2nzadQDUZwAAw4nQABW/obAAAiXMYAARX/hAAAHj4LAABksXMA==
Thread-topic: [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
Keir> uniformly in the common code. Of course we can treat the idle
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

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.


Xen-devel mailing list