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: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
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 08:17:51 -0700
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 14 Jul 2005 15:16:33 +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: AcWIhZxFzHuD9NLkS2yp1bh5FcViMAAANQ1Q
Thread-topic: [Xen-devel] RE: [Patch] Fix IDLE issue with sedf scheduler on IA64
> > 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.
> I think that what you execute during idle time, and what state you 
> save/restore, is orthogonal to how you represent the idle 
> state to the 
> scheduler and other subsystems in the hypervisor.

Which is exactly my point... The existing paradigm for schedulers
mixes/confuses the two because scheduling the idle process/thread/domain
is a convenient way for a scheduler to report that it has nothing

Xen-devel mailing list