[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181119204025.GL14688@zn.tnic>
Date: Mon, 19 Nov 2018 21:40:25 +0100
From: Borislav Petkov <bp@...en8.de>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
John Stultz <john.stultz@...aro.org>,
Tom Lendacky <Thomas.Lendacky@....com>
Subject: Re: [PATCH] x86/TSC: Use RDTSCP
On Mon, Nov 19, 2018 at 12:17:35PM -0800, H. Peter Anvin wrote:
> On 11/19/18 11:52 AM, Andy Lutomirski wrote:
> >
> > I thought I benchmarked this on Intel at some point and found the
> > LFENCE;RDTSC variant to be slightly faster. But I believe you, so:
> >
> > Acked-by: Andy Lutomirski <luto@...nel.org>
> >
>
> As long as the difference isn't significant, the simplicity would seem to be a
> win.
Right, I think by simplicity you mean RDTSCP. :)
Also in the sense that you have a single instruction which gives you
that barrier of waiting for all older insns to retire before reading the
TSC vs two where you don't necessarily know what happens on the uarch
level. I mean, nothing probably happens but RDTSCP is still simpler :)
Also, hpa, isn't LFENCE; RDTSC and RDTSCP equivalent on Intel? In the
sense that RDTSCP microcode practically adds an LFENCE before reading
the TSC?
Because SDM says:
"The RDTSCP instruction is not a serializing instruction, but it does
wait until all previous instructions have executed and all previous
loads are globally visible."
which sounds pretty much like an LFENCE to me:
"LFENCE does not execute until all prior instructions have completed
locally, and no later instruction begins execution until LFENCE
completes."
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Powered by blists - more mailing lists