From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: pvclock (PV and HVM) and vsyscall Date: Fri, 15 Oct 2010 17:28:25 -0700 Message-ID: <4CB8F1A9.4080909@goop.org> References: 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: Dan Magenheimer Cc: xen-devel@lists.xensource.com, Tim Deegan , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 10/15/2010 08:48 AM, Dan Magenheimer wrote: > The other discussion of RADclock reminded me: > > IIRC the pvclock algorithm is still incompatible with > vsyscall/vdso (fast system calls) and there was no obvious > and upstreamable solution to resolve this. > > This means that any userland call to the various gettimeofday > routines will always do a true system call on both (a) a PV > domain or (b) any PV on HVM domain with Stefanos' pvclock patch. > > Since true syscalls are very expensive on a 64-bit > PV domain, I'm wondering if pvclock is still the right > default choice for upstream (at least for 64-bit). What other options are there? If the tsc is globally stable, then using pvclock in userspace will work fine; if it isn't, you'll need to do the syscall anyway. There's no basic problem with the vsyscall pvclock patch so long as we can know under what circumstances it is safe to enable. J