RE: [Xen-devel] Re: 0/4 Xen Scheduling Groups

["Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>]

> >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
domain.
> 
> 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
worlds.

Ian

[*] 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
scheduler]  

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel