[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCHv4 0/11] Xen: FIFO-based event channel ABI
>>> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |