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

Re: [Xen-devel] [PATCH] Don't trigger unnecessary shadow scans on p2m entry update



Not sure about that. We need to check for either of two conditions on 
page->count_info. That it's zero, or that it's PGC_allocated | 1.

(__count & (PGC_count_mask|PGC_allocated)) matched against (1|PGC_allocated) 
would lose the zero case.

Resubmitting shortly.
Andres 

On Nov 25, 2011, at 4:18 AM, Keir Fraser wrote:

> On 25/11/2011 08:45, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
>>>>> On 24.11.11 at 19:31, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
>>> On 24/11/2011 17:58, "Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx> wrote:
>>>> @@ -815,6 +815,12 @@ static inline unsigned long vtlb_lookup(
>>>> }
>>>> #endif /* (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB) */
>>>> 
>>>> +static inline int __check_page_no_refs(struct page_info *page)
>>>> +{
>>>> +    unsigned long __count = page->count_info;
>>>> +    return ( (__count & PGC_count_mask) ==
>>>> +             ((__count & PGC_allocated) ? 1 : 0) );
>>> 
>>> It's a fussy point, but it might be better to use
>>> atomic_read_ulong(&page->count_info) here, to ensure that the compiler reads
>>> the field once only. It's cheap (compiles to a single mov instruction), but
>>> atomic_read_ulong doesn't exist so you'd have to add its (obvious)
>>> definition to asm-x86/atomic.h
>> 
>> I think Tim suggested anyway to use
>> 
>> (__count & (PGC_count_mask|PGC_allocated)) matched against
>> (1|PGC_allocated) here, which would eliminate the multiple read
>> potential if used in a switch statement.
> 
> Yes, that would be better.
> 
> -- Keir
> 
>> Also, for clarity the function should probably return bool_t.
>> 
>> Jan
>> 
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.