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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.08.13 at 17:46, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
> 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?

Depends on the amount of extra complexity.

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

Hmm, that's with the 17 bits you currently use? And would double
with each eventual increment? A 2-element array is certainly fine
in struct domain, but we ought to set some boundary (e.g. via
BUILD_BUG_ON()) to trigger implementation of dynamic allocation
then.

Jan


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