[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |