From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>,
David Vrabel <david.vrabel@citrix.com>,
xen-devel@lists.xen.org
Subject: Re: [PATCHv4 0/11] Xen: FIFO-based event channel ABI
Date: Tue, 1 Oct 2013 10:22:40 -0400 [thread overview]
Message-ID: <20131001142240.GC5913@phenom.dumpdata.com> (raw)
In-Reply-To: <524ABF5702000078000F843E@nat28.tlf.novell.com>
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@oracle.com> 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
>
next prev parent reply other threads:[~2013-10-01 14:22 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-27 10:55 [PATCHv4 0/11] Xen: FIFO-based event channel ABI David Vrabel
2013-09-27 10:55 ` [PATCH 01/11] debug: remove some event channel info from the 'i' and 'q' debug keys David Vrabel
2013-09-27 10:55 ` [PATCH 02/11] evtchn: refactor low-level event channel port ops David Vrabel
2013-09-27 10:55 ` [PATCH 03/11] evtchn: print ABI specific state with the 'e' debug key David Vrabel
2013-09-27 10:55 ` [PATCH 04/11] evtchn: use a per-domain variable for the max number of event channels David Vrabel
2013-09-27 10:55 ` [PATCH 05/11] evtchn: allow many more evtchn objects to be allocated per domain David Vrabel
2013-09-27 10:55 ` [PATCH 06/11] evtchn: add FIFO-based event channel ABI David Vrabel
2013-09-27 10:55 ` [PATCH 07/11] evtchn: implement EVTCHNOP_set_priority and add the set_priority hook David Vrabel
2013-09-27 10:55 ` [PATCH 08/11] evtchn: add FIFO-based event channel hypercalls and port ops David Vrabel
2013-09-27 12:34 ` Jan Beulich
2013-09-27 10:55 ` [PATCH 09/11] xen: Add DOMCTL to limit the number of event channels a domain may use David Vrabel
2013-09-27 12:40 ` Jan Beulich
2013-09-27 14:29 ` Daniel De Graaf
2013-09-27 10:55 ` [PATCH 10/11] libxc: add xc_domain_set_max_evtchn() David Vrabel
2013-10-01 12:30 ` Ian Campbell
2013-09-27 10:55 ` [PATCH 11/11] libxl, xl: add event_channels option to xl configuration file David Vrabel
2013-10-01 12:36 ` Ian Campbell
2013-10-01 12:53 ` David Vrabel
2013-09-27 12:41 ` [PATCHv4 0/11] Xen: FIFO-based event channel ABI Jan Beulich
2013-09-30 18:41 ` Konrad Rzeszutek Wilk
2013-10-01 10:25 ` Jan Beulich
2013-10-01 14:22 ` Konrad Rzeszutek Wilk [this message]
2013-10-01 14:41 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131001142240.GC5913@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=JBeulich@suse.com \
--cc=david.vrabel@citrix.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).