From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753940AbbDRQU4 (ORCPT ); Sat, 18 Apr 2015 12:20:56 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:36833 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753627AbbDRQUw (ORCPT ); Sat, 18 Apr 2015 12:20:52 -0400 Message-ID: <5532845E.3040107@redhat.com> Date: Sat, 18 Apr 2015 18:20:46 +0200 From: Paolo Bonzini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Andy Lutomirski , Linus Torvalds CC: John Stultz , Marcelo Tosatti , Peter Zijlstra , "linux-kernel@vger.kernel.org" , Gleb Natapov , kvm list , Ralf Baechle , Andrew Lutomirski Subject: Re: [GIT PULL] First batch of KVM changes for 4.1 References: <20150417091745.GA24151@twins.programming.kicks-ass.net> <5530DBED.5080508@redhat.com> <20150417103654.GE5029@twins.programming.kicks-ass.net> <5530E28F.2030401@redhat.com> <20150417105506.GF5029@twins.programming.kicks-ass.net> <553100C1.5000408@redhat.com> <20150417131037.GG23123@twins.programming.kicks-ass.net> <55310CF2.6070107@redhat.com> <20150417190146.GA24395@amt.cnet> <55316598.908@redhat.com> <20150417201841.GA31302@amt.cnet> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18/04/2015 00:25, Andy Lutomirski wrote: >> Isn't the *whole* point of pvclock_clocksource_read() to be a native >> rdtsc with scaling? How does it cause that kind of insane pain? It's possible that your machine ends up with PVCLOCK_TSC_STABLE_BIT clear, so you get an atomic cmpxchg in addition (and associated cacheline bouncing, since anything reading the clocksource in the kernel will cause that variable to bounce). But that's not too common on recent machines. Is the vsyscall faster for you or does it degenerate to the syscall? If so, you have PVCLOCK_TSC_STABLE_BIT clear. > An unnecessarily complicated protocol, a buggy host implementation, > and an unnecessarily complicated guest implementation :( pvclock_clocksource_read() itself is not scary and need not worry about the buggy host implementation (preempt_disable makes things easy). It's the vDSO stuff that has the nice things. There's a few micro-optimizations that we could do (the guest implementation _is_ unnecessarily baroque), but it may not be enough if the rdtsc_barrier()s (lfence) are the performance killers. Will look closely on Monday. Paolo >> Oh well. Some paravirt person would need to look and care. > > The code there is a bit scary. > > --Andy > >> >> Linus > > >