From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCHv4 0/11] Xen: FIFO-based event channel ABI Date: Tue, 1 Oct 2013 10:22:40 -0400 Message-ID: <20131001142240.GC5913@phenom.dumpdata.com> References: <1380279359-28817-1-git-send-email-david.vrabel@citrix.com> <20130930184138.GC5211@phenom.dumpdata.com> <524ABF5702000078000F843E@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <524ABF5702000078000F843E@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Keir Fraser , David Vrabel , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Tue, Oct 01, 2013 at 11:25:59AM +0100, Jan Beulich wrote: > >>> On 30.09.13 at 20:41, Konrad Rzeszutek Wilk 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. 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. Then there is the blk event channel, the tx/rx of the vif. With the possibility of per-cpu tx/rx of vifs you would have 2*VCPU, so now we are at 288. If you want even more LUNS (say 16), you are at 304. 1023 being the universal value looks OK to me. > > Jan >