Re: [Xen-devel] [PATCHv6 5/5] gnttab: use per-VCPU maptrack free lists

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 24.04.15 at 12:21, <malcolm.crossley@xxxxxxxxxx> wrote:
> On 24/04/15 10:50, Jan Beulich wrote:
>>>>> On 24.04.15 at 11:09, <malcolm.crossley@xxxxxxxxxx> wrote:
>>> On 23/04/15 17:11, Jan Beulich wrote:
>>>>>>> On 22.04.15 at 18:00, <david.vrabel@xxxxxxxxxx> wrote:
>>>>> --- a/xen/include/xen/grant_table.h
>>>>> +++ b/xen/include/xen/grant_table.h
>>>>> @@ -60,6 +60,8 @@ struct grant_mapping {
>>>>>      u32      ref;           /* grant ref */
>>>>>      u16      flags;         /* 0-4: GNTMAP_* ; 5-15: unused */
>>>>>      domid_t  domid;         /* granting domain */
>>>>> +    u32      vcpu;          /* vcpu which created the grant mapping */
>>>>> +    u16      pad[2];
>>>>>  };
>>>>
>>>> What is this pad[] good for?
>>>
>>> The pad is to keep the struct power of 2 sized because this allows the
>>> compiler to optimise these macro's to right and left shifts:
>>>
>>> #define MAPTRACK_PER_PAGE (PAGE_SIZE / sizeof(struct grant_mapping))
>>> #define maptrack_entry(t, e) \
>>>     ((t)->maptrack[(e)/MAPTRACK_PER_PAGE][(e)%MAPTRACK_PER_PAGE])
>> 
>> Okay, then why u16[2] instead of u32? And please add a brief
>> comment explaining the reason.
>> 
>> Apart from that I wonder whether fitting vcpu in the 10 unused
>> flags bits (not 11, as the comment on the field suggests) would be
>> an option. That would require limiting vCPU count to 4k, which I
>> don't think would really be a problem for anyone.
> 
> I'd like to not have the overhead of bit operations on a hot path.
> 
> We're going from 512 grant entries per page to 256 grant entries per
> page. This is taking the Xen memory overhead from 0.2% to 0.4% for grant
> mapped pages.
> 
> Is the extra 0.2% memory overhead that concerning?

Perhaps not so much the memory overhead but the doubled
cache bandwidth needed. But anyway, this was only a
question, and with both you and Andrew being opposed let's
just stay with what you submitted.

Jan


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