From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Re: [PATCH] x86: unconditionally mark TSC unstable under Xen Date: Thu, 15 Jul 2010 09:30:29 -0700 Message-ID: <4C3F37A5.9050606@goop.org> References: <51C8308F-F413-47AF-8845-C92BD36CA35C@linode.com> <4C3E2DCC.1010201@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefano Stabellini Cc: "xen-devel@lists.xensource.com" , Jed Smith , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 07/15/2010 08:57 AM, Stefano Stabellini wrote: > On Wed, 14 Jul 2010, Jeremy Fitzhardinge wrote: > >> Subject: [PATCH] xen: disable xen_sched_clock by default >> >> xen_sched_clock only counts unstolen time. In principle this should >> be useful to the Linux scheduler so that it knows how much time a process >> actually consumed. But in practice this doesn't work very well as the >> scheduler expects the sched_clock time to be synchronized between >> cpus. It also uses sched_clock to measure the time a task spends >> sleeping, in which case "unstolen time" isn't meaningful. >> >> So just use plain xen_clocksource_read to return wallclock nanoseconds >> for sched_clock. >> >> > I think that in this context is worth mentioning that > xen_clocksource_read ends up calling pvclock_get_nsec_offset that calls > native_read_tsc. > That's different. That's not a general rdtsc, but a specific use of the tsc within the Xen clock ABI. We know and expect that the raw tsc value could be dubious, but we also have the Xen-provided corrections to apply to it. J