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

RE: [Xen-devel] [PATCH] x86: don't write_tsc() non-zero values on CPUs updating only the lower 32 bits



> From: Keir Fraser [mailto:keir.xen@xxxxxxxxx]
> Sent: Friday, April 15, 2011 12:40 AM
> To: Dan Magenheimer; Jan Beulich
> Cc: winston.l.wang; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH] x86: don't write_tsc() non-zero values
> on CPUs updating only the lower 32 bits
> 
> On 14/04/2011 23:41, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
> wrote:
> 
> >> Yeah, if we want to continue to try avoiding write_tsc() on
> >> TSC_RELIABLE
> >> then we should assert !TSC_RELIABLE on the write_tsc() path in
> >> cstate_tsc_restore().
> >
> > Agreed.  In fact, maybe it should be asserted in write_tsc?
> 
> We still write_tsc on CPU physical hot-add.

Hmmm... IIRC the testing that Intel was doing for hot-add was
not for processors that were actually electrically hot-plugged
but only for processors that were powered-on at the same
time as all other processors but left offline until needed
(e.g. for capacity-on-demand).  For this situation, writing
to tsc is still the wrong approach.  I don't think we finished
the discussion about electrically hot-plugged processors
because they didn't exist... don't know if they do yet either.
IIRC I had proposed an unnamed boot parameter that said
"this machine may add unsynchronized processors post-boot"
and disallow hot-add processors if not specified (or if
not specified AND a run-time check of a hot-add processor
shows non-synchronization).

Dan

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