Re: [SPAM] Re: [Xen-devel] A patch to xen/arch/x86/hvm/pmtimer.c for both Xen 4.0.0 and Xen 4.0.1 to improve HVM scalability

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> On 16.11.10 at 08:48, Keir Fraser <keir@xxxxxxx> wrote:
> On 16/11/2010 14:51, "Song Xiang" <classicxsong@xxxxxxxxx> wrote:
> 
>> +        /*
>> +         * if acquired the PMTState lock then update the time
>> +         * else other vcpu is updating it ,it should be up to date.
>> +         */
>> +        tmp = atomic_read(&s-> ownership);
>> +        if (spin_trylock(&s->lock)) {
>> +            pmt_update_time(s);
>> +            *val = s->pm.tmr_val;
>> +            spin_unlock(&s->lock);
>> +            atomic_inc(&s-> ownership);
>> +        }
>> +        else {
>> +            while (tmp == atomic_read(&s-> ownership));
> 
> You've kind of implemented a spin_barrier(). What you implemented could be
> better and equivalently done as something like:
> 
> if (spin_trylock(&s->lock)) {
>   ...
> } else {
>   spin_barrier(&s->lock);
> }
> 
> No need for your new field at all! It initially seems weird that this
> performs much better than the original code, but I guess it might: if all
> VCPUs are piling in here at the same time, rather than having to execute one
> by one, we'll have one go first and then the others will all execute
> simultaneously read-only in convoy...

They'd need to re-measure whether this still provides a meaningful
benefit, I think.

Jan


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