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: 0/4 Xen Scheduling Groups

To: <ncmike@xxxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] Re: 0/4 Xen Scheduling Groups
From: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>
Date: Mon, 14 May 2007 15:18:33 +0100
Cc: Atsushi SAKAI <sakaia@xxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 14 May 2007 07:17:11 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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>
References: <20070512001614.GB13507@xxxxxxxxxxxxxxxxxxxxxx><C26B2EAF.744B%Keir.Fraser@xxxxxxxxxxxx> <20070514132324.GC13507@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AceWKzXePeD18UKtSQ22TZ0MVu8grAABZamQ
Thread-topic: [Xen-devel] Re: 0/4 Xen Scheduling Groups
> >I thought we decoded the instruction to be emulated in Xen (in the
> context
> >of the HVM domain, so current==hvm-domain) then packaged it up in a
> >shared-memory page and notified qemu-dm in dom0 via an event channel.
> To my
> >knowledge there's no special treatment of this event channel or of
> dom0: the
> >notification is treated just like any wake-up of any arbitrary
> Hi Keir, thanks for clarifying. Has anyone considered giving priority
> to dom0 (or any domain) when a domU is blocking on completion of an
> event being handled by dom0?

It's not entirely clear that eagerly scheduling dom0 is the best thing
to do -- in fact, some of Lucy's data suggested that schedulers that
tended to be less eager to pre-empt promoted more batching and hence
better throughput. 

My preferred way of tackling this is to make promotion of batching more
explicit by implementing either a 'deferred send' or 'lazy receive'[*]
for event channel notifications. If we have these, it shouldn't matter
if we're eager to schedule dom0, for h/w interrupts, which intuitively
what we should be doing.

It might be instructive to implement strict priority for dom0 and
confirm that it makes things worse under at least some IO workloads
(particularly network ones). It would then be nice to implement deferred
send or lazy receive to then see whether this gives us the best of both


[*] deferred send would enable a domain to request that a notification
be sent in X nanoseconds, or whenever it blocks, which ever comes
sooner. If it has one of these deferred notifications outstanding it can
still trigger the notification immediately by using the normal send
event call. [only when the notification actually happens does the
receiving domain unblock and hence be eligible to be selected by the

Lazy receive has a similar effect to deferred send, and is very similar
to what modern NICs do. It would enable a domain to say that for a
particular event channel it wants to be unblocked X nanoseconds after
the event becomes pending rather than immediately. There are pros and
cons to both approaches, and they're not necessarily mutually exclusive.

Xen-devel mailing list