Re: [GIT PULL] First batch of KVM changes for 4.1

From: Paolo Bonzini <pbonzini@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: John Stultz <john.stultz@linaro.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Gleb Natapov <gleb@kernel.org>, kvm list <kvm@vger.kernel.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Andrew Lutomirski <luto@kernel.org>
Subject: Re: [GIT PULL] First batch of KVM changes for 4.1
Date: Sat, 18 Apr 2015 18:20:46 +0200	[thread overview]
Message-ID: <5532845E.3040107@redhat.com> (raw)
In-Reply-To: <CALCETrVc-kdvs2xPi6rDwYt7E+b=q_GXU+tdrgQEopmOUDAgrQ@mail.gmail.com>

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
> 
> 
> 