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

Re: [Xen-devel] [PATCH 6/8] evtchn: alter internal object handling scheme



On 15/08/13 15:21, Jan Beulich wrote:
>>>> On 09.08.13 at 20:08, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
>> +#define BUCKETS_PER_GROUP  (PAGE_SIZE/sizeof(struct evtchn *))
>> +/* Round size of struct evtchn up to power of 2 size */
>> +#define b2(x)   (   (x) | (   (x) >> 1) )
>> +#define b4(x)   ( b2(x) | ( b2(x) >> 2) )
>> +#define b8(x)   ( b4(x) | ( b4(x) >> 4) )
>> +#define b16(x)  ( b8(x) | ( b8(x) >> 8) )
>> +#define b32(x)  (b16(x) | (b16(x) >>16) )

>> +/* Maximum number of event channels for any ABI. */
>> +#define MAX_NR_EVTCHNS (max_t(unsigned, NR_EVENT_CHANNELS,  \
>> +                              1 << EVTCHN_FIFO_LINK_BITS))
> 
>> +#define EVTCHNS_PER_BUCKET (PAGE_SIZE / next_power_of_2(sizeof(struct 
>> evtchn)))
>> +#define EVTCHNS_PER_GROUP  (BUCKETS_PER_GROUP * EVTCHNS_PER_BUCKET)
>> +#define NR_EVTCHN_GROUPS   DIV_ROUND_UP(MAX_NR_EVTCHNS, EVTCHNS_PER_GROUP)
> 
> So for the 2-level case this still results in a full page allocation for
> the top level structure. Not too nice...

Without XSM enabled sizeof(struct evtchn) is 32 so:

EVTCHNS_PER_BUCKET = 128
BUCKETS_PER_GROUP = 512
NR_EVTCHN_GROUPS = 2

The minimal allocation is then:

1 bucket page, 1 group page and 16 bytes[*] for the group pointers.

Which I agree is 1 page more than previously.  Is saving 1 xenheap page
per domain worth adding extra complexity to the lookup?

We could drop patch 4 (dynamically allocate d->evtchns) and have a array
in struct domain since it is only a 2 element array.

David

[*] not sure what the minimum size for a xmalloc() allocation is.  Is it
actually 128 bytes?

_______________________________________________
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®.