[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 03.01.13 at 12:33, Wei Liu <Wei.Liu2@xxxxxxxxxx> wrote:
> On Thu, 2013-01-03 at 10:36 +0000, Jan Beulich wrote:
>> >>> On 02.01.13 at 15:27, Wei Liu <Wei.Liu2@xxxxxxxxxx> 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@xxxxxxxxx>
>> >> 
>> >> 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.

Yes, alloc_xenheap_page() is the right thing to use for exact page
size allocations. There's no tracking structure associated with that
(other than struct page_info, which exists regardless of that
allocation).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.