[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
>>> 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |