Re: [Xen-devel] [PATCHv4 0/11] Xen: FIFO-based event channel ABI

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.10.13 at 16:22, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
> On Tue, Oct 01, 2013 at 11:25:59AM +0100, Jan Beulich wrote:
>> >>> On 30.09.13 at 20:41, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 
>> >>> wrote:
>> > On Fri, Sep 27, 2013 at 11:55:48AM +0100, David Vrabel wrote:
>> >> This is a complete implementation of the hypervisor and xl toolstack
>> >> parts of the FIFO-based event channel ABI described in this design
>> >> document:
>> >> 
>> >> http://xenbits.xen.org/people/dvrabel/event-channels-F.pdf 
>> >> 
>> >> Changes in draft F are:
>> >> 
>> >> - READY field in the control block is now 32-bits (so guests only need
>> >>   to support atomic bit ops on 32-bit words).  This is only a
>> >>   documentation change as the implementation already used a uint32_t.
>> >> 
>> >> - DOMCTL_set_max_evtchn replaces EVTCHNOP_set_limit.
>> >> 
>> >> - DomUs default to unlimited number of event channels requiring
>> >>   the toolstack to set a limit.
>> >> 
>> >> The toolstack defaults to limiting guests to 127 event channels if the
>> >> event_channels option is omitted.  This means the minimum amount of
>> >> both Xen heap and global mapping space is used regardless of which ABI
>> >> is used.  If this is considered too restrictive a limit, 1023 would be
>> >> another sensible default (limits the guest to a single event array
>> >> page but 5 xenheap pages for the struct evtchns).
>> > 
>> > I would say 1023 (so the same value as the existing event mechanism)
>> > would be a sensible default.
>> 
>> That's the existing 32-bit default; 64-bit has 4095 (yet that surely
>> would be needlessly high as the new default).
> 
> 127 is too little I think.

I agree; I'm fine with defaulting to 1023 (I only wanted to point
out that other than you claimed this is lower than the 2-level
default on 64-bit guests). Perhaps the tools could even be
intelligent enough to make the default depend on the vCPU count
of the guest.

> For example for every VCPU there are 6 events
> being consumed (VIRQ_TIMER, VIRQ_DEBUG, CALLFUNCSINGLE, CALLFUNC, RESCHED
> and IRQWORK). If you launch a 32 VCPU guest you are already at 224.

Because you waste them - all the IPI flavors could collectively do
with just one event channel per vCPU (as our more recent kernels
do).

You of course need a separate one for the timer, and you forgot
the spin lock polling one. Whether the VIRQ_DEBUG one is always
necessary I'm not sure - I would think the kernel should by default
avoid registering it.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel