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

[Keir Fraser <keir@xxxxxxx>]

On 16/11/2010 07:54, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

>> 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.

Definitely. I explicitly asked for that.

Oh, also the approach is currently buggy. Although s->pm.tmr_val is atomic
to read, it is not atomically updated in pmt_update_time(). Need to
calculate new value for tmr_val in a local variable then update the shared
field with an atomic_set()-alike *(volatile u32 *)&s->pm.tmr_val = x type of
arrangement.

For all this extra fragility, the perf win needs to be compelling.

 -- Keir



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