From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: George Dunlap <dunlapg@umich.edu>
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: Request for input: Extended event channel support
Date: Fri, 29 Mar 2013 09:05:01 -0400 [thread overview]
Message-ID: <20130329130501.GA31497@phenom.dumpdata.com> (raw)
In-Reply-To: <CAFLBxZa98gw3gTOHBHUWkiyBBzSq9UZNZ1f7BJ895SJPYszTJw@mail.gmail.com>
> * What we need to know
>
> What we're missing in order to make an informed decision is voices
> from the community: If we delay the event channel scalability feature
> until 4.4, how likely is this to be an issue? Are there current users
> or potential users of Xen who need to be able to scale past 200 VMs on
> a single host, and who would end up choosing another hypervisor if
> this feature were delayed?
For this to work you also need the Linux side patches. That means
that if you want to hit this in v3.10 merge window you have until
April 15th to get it in. The reason is that I am out from
April 20th, and the merge window will probably be open on May 1st.
We need at least one week to work out any bugs when it goes
in #linux-next - hence the April 15th deadline.
Technically sounding, the FIFO looks more appealing than the three
level events, but that is a subjective opinion.
The reality is that what should be really determined is which one
will give better performance. From a design perspective it looks
as FIFO is the clear winner, but perhaps not - I only briefly looked
over the paper?
Anyhow, I am leaning towards the FIFO - but I think that if there are
existing people who want this functionality _Right now_, then
the 3-level event channels would offer a stop-gate option. And they
can apply it to their hypervisor + Linux by hand right?
>
> Thank you for your time and input.
>
> -George Dunlap,
> 4.3 Release manager
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
next prev parent reply other threads:[~2013-03-29 13:05 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-27 11:23 Request for input: Extended event channel support George Dunlap
2013-03-27 19:36 ` Anil Madhavapeddy
2013-03-27 21:53 ` David Vrabel
2013-03-27 22:28 ` Anil Madhavapeddy
2013-03-27 22:31 ` Wei Liu
2013-03-28 12:51 ` Felipe Franciosi
2013-03-28 12:54 ` Anil Madhavapeddy
2013-03-28 13:02 ` Felipe Franciosi
2013-04-10 10:45 ` [Xen-users] " Ian Campbell
2013-04-10 16:14 ` Anil Madhavapeddy
2013-04-10 10:45 ` Ian Campbell
2013-03-28 1:56 ` Konrad Rzeszutek Wilk
2013-03-28 11:10 ` George Dunlap
2013-03-28 11:34 ` Jan Beulich
2013-03-29 13:05 ` Konrad Rzeszutek Wilk [this message]
2013-04-02 7:44 ` Jan Beulich
2013-04-02 14:20 ` Konrad Rzeszutek Wilk
2013-04-04 13:31 ` George Dunlap
2013-04-10 10:49 ` [Xen-users] " Ian Campbell
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=20130329130501.GA31497@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=dunlapg@umich.edu \
--cc=xen-devel@lists.xen.org \
--cc=xen-users@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.