Re: [Xen-devel] [PATCH v2] x86/PoD: shorten certain operations on higher order ranges

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.09.15 at 14:20, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 28/09/15 15:30, Jan Beulich wrote:
>> --- a/xen/arch/x86/mm/p2m-pod.c
>> +++ b/xen/arch/x86/mm/p2m-pod.c
>> @@ -119,20 +119,23 @@ p2m_pod_cache_add(struct p2m_domain *p2m
>>  
>>      unlock_page_alloc(p2m);
>>  
>> -    /* Then add the first one to the appropriate populate-on-demand list */
>> -    switch(order)
>> +    /* Then add to the appropriate populate-on-demand list. */
>> +    switch ( order )
>>      {
>> +    case PAGE_ORDER_1G:
>> +        for ( i = 0; i < (1UL << PAGE_ORDER_1G); i += 1UL << PAGE_ORDER_2M )
>> +            page_list_add_tail(page + i, &p2m->pod.super);
>> +        break;
>>      case PAGE_ORDER_2M:
>> -        page_list_add_tail(page, &p2m->pod.super); /* lock: page_alloc */
>> -        p2m->pod.count += 1 << order;
>> +        page_list_add_tail(page, &p2m->pod.super);
>>          break;
>>      case PAGE_ORDER_4K:
>> -        page_list_add_tail(page, &p2m->pod.single); /* lock: page_alloc */
>> -        p2m->pod.count += 1;
>> +        page_list_add_tail(page, &p2m->pod.single);
>>          break;
>>      default:
>>          BUG();
>>      }
>> +    p2m->pod.count += 1 << order;
> 
> 1UL

Not really - the field is a "long" one, so at best 1L or 1U. And then
all the valid order values are visible right above, for none of them
it makes a difference, and there are ample similar uses scattered
around the file (yes, bad examples are no excuse, but in cases
where the suffix doesn't really matter I think it is better to omit it).

> Otherwise, Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Let me know regrading this one,
Jan


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