[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <98718c79-d589-3689-3c59-6ca158148641@zytor.com>
Date: Thu, 8 Jun 2023 17:14:10 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: David Laight <David.Laight@...LAB.COM>,
"'Thomas Gleixner'" <tglx@...utronix.de>,
Muhammad Usama Anjum <usama.anjum@...labora.com>,
Jonathan Corbet <corbet@....net>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>,
"Guilherme G. Piccoli" <gpiccoli@...lia.com>
Cc: Steven Noonan <steven@...inklabs.net>,
"kernel@...labora.com" <kernel@...labora.com>
Subject: Re: Direct rdtsc call side-effect
On 6/6/23 01:23, David Laight wrote:
>
> IIRC the x86 performance counters aren't dependent on anything
> so they tend to execute much earlier than you want.
> OTOH rdtsc is likely to be synchronising and affect what follows.
> ISTR using rdtsc to wait for instructions to complete and then
> the performance clock counter to see how long it took.
>
RDPMC and RDTSC have the same (lack of) synchronization guarantees; you
need to fence them appropriately for your application no matter what.
-hpa
Powered by blists - more mailing lists