From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: rdtsc hypercall, from userland?!? (was: rdtsc: correctness vs performance on Xen) Date: Wed, 09 Sep 2009 11:59:11 -0700 Message-ID: <4AA7FAFF.20505@goop.org> References: <6dfe825c-f49e-402e-81d0-e8eaee3c9cda@default> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <6dfe825c-f49e-402e-81d0-e8eaee3c9cda@default> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer Cc: "Xen-Devel (E-mail)" , Keir Fraser , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 09/09/09 11:05, Dan Magenheimer wrote: > BUT > (IMPORTANT NEW POINT!!!) the pvclock algorithm requires > an rdtsc instruction, and there is no way to > emulate some guest rdtsc instructions (e.g. only > those in apps) and not others (e.g. only those in > the kernel). Thus, for guests that have rdtsc emulation > enabled, vsyscall+pvclock will be SLOWER than emulation, > thus meaning it is still not a palatable alternative. > You could enable/disable emulation rdtsc each context switch according to the app's desires/requrements. It would require an extra hypercall per context switch, but it could be batched with the others, resulting in little marginal cost. It would, however, leave the kernel's use of rdtsc in a confused state. J