Re: [RFC PATCH 2/3] Dynamically allocate domain->evtchn, also bump EVTCHNS_PER_BUCKET to 512.

[Wei Liu <Wei.Liu2@citrix.com>]

On Thu, 2013-01-03 at 10:36 +0000, Jan Beulich wrote:
> >>> On 02.01.13 at 15:27, Wei Liu <Wei.Liu2@citrix.com> wrote:
> > On Wed, 2013-01-02 at 13:38 +0000, David Vrabel wrote:
> >> On 31/12/12 18:22, Wei Liu wrote:
> >> > From: Wei Liu <liuw@liuw.name>
> >> 
> >> The changeset description needs to say why you're increasing
> >> EVTCHNS_PER_BUCKET.  I can't tell why.
> >> 
> > 
> > Here is the tedious maths. My thought was that it is not very
> > interesting to see this in a change log, so I dropped it. But I will add
> > this in my later re-post of this series...
> > 
> > #define EVTCHNS_PER_BUCKET ???
> > #define NR_EVTCHN_BUCKETS (NR_EVENT_CHANNEL_L3/EVTCHNS_PER_BUCKET)
> > d->evtchn = xzalloc_array(struct evtchn *, NR_EVTCHN_BUCKETS);
> > 
> > We need to allow for 3-level evtchn, so use NR_EVENT_CHANNELS_L3 to
> > calculate NR_EVTCHN_BUCKETS.
> > 
> > For 64 bit build, NR_EVENT_CHANNELS_L3 is 256k. The original value of
> > EVTCHNS_PER_BUCKET is 128, which means NR_EVTCHN_BUCKETS=2048, thus
> > d->evtchn has size of 2048*8 = 16KB = 4 pages. Given that only Dom0 or
> > driver domain will need 3-level event channel, this is really overkill
> > for most guests.
> > 
> > If we bump EVTCHNS_PER_BUCKET to 512, d->evtchn becomes 512 * 8 = 4KB =
> > 1 page, which I think is more space efficient for most guests.
> 
> But not suitable for allocation through xmalloc() (as it'll end up
> doing an order-1 page allocation). Either special case it here, or
> BUILD_BUG_ON() the effective size being exactly a page, or we
> may look into finally making xmalloc() return a page with no
> other tracking data when asked for exactly a page's worth of
> bytes.
> 

Is alloc_xen_heap_page suitable? But I presume there is always some
tracking structure somewhere, so I didn't even take that into account
when I did calculation.

Can you give me some pointers, thanks.


Wei.