From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: RE: [RFC] Physical hot-add cpus and TSC Date: Thu, 27 May 2010 08:08:24 -0700 (PDT) Message-ID: <3c99c55d-68ce-4150-b895-72fda1ff3b89@default> References: <789F9655DD1B8F43B48D77C5D30659731E78D370@shsmsx501.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <789F9655DD1B8F43B48D77C5D30659731E78D500@shsmsx501.ccr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Jiang, Yunhong" , Keir Fraser , "Xen-Devel (xen-devel@lists.xensource.com)" , Ian Pratt List-Id: xen-devel@lists.xenproject.org > >From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] > > > >I implemented this as xen-unstable:21468. This represents a strict > >improvement on what was in xen-unstable before that (no tsc sync at > all, > >ever, because I deleted it about a week ago). Open to further > improvements, > >if we can get consensus. >=20 > Thanks for the patch. I will get the system that support CPU hotplug > tomorrow morning, I can try it then. >=20 > --jyh Hmmm... I'd be very surprised if this works ever, let alone always across all hardware. By "work", I mean that it will result in an "undetectably small difference" (less than a cache bounce), as defined and measured by the tsc warp test. Why? Because rdtsc is a long instruction (30-100 cycles) and I'll bet writing to the TSC is even longer. Plus, there's a cache bounce overhead added in due to the synchronization via the in-memory tsc_count variable. Our firmware guys say that TSC synchronization can't be implemented algorithmically in firmware... it requires a simultaneous "reset" signal to all sockets/cores, which is obviously not an option here.