Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Rong Tao <rtoax@foxmail.com>
Cc:     rtoax@foxmail.com, Rong Tao <rongtao@cestc.cn>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
        "H. Peter Anvin" <hpa@zytor.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/vdso: Use non-serializing instruction rdtsc
In-Reply-To: <tencent_4DC4468312A1CB2CA34B0215FAD797D11F07@qq.com>
Date:   Tue, 16 May 2023 16:20:09 +0200
Message-ID: <87ttwc73za.ffs@tglx>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Rong!

On Tue, May 16 2023 at 14:52, Rong Tao wrote:
> Replacing rdtscp or 'lfence;rdtsc' with the non-serializable instruction
> rdtsc can achieve a 40% performance improvement with only a small loss of
> precision.

That rdtsc_ordered() is not there to achieve precision. It's there to
guarantee correctness. The correctness requirement is that reading clock
MONOTONIC is strictly monotonic, i.e. there is no way that you can
observe time going backwards. Neither locally nor accross CPUs.

As you explained:

> The RDTSC instruction is not a serializing instruction.  It does not
> necessarily wait until all previous instructions have been executed
> before reading the counter.

Q: What guarantees that this does not speculate deep enough to actually
   make time go backwards?

A: Nothing

Conclusion: The fence stays, unless you can prove the contrary under all
circumstances and microarchitecture generations.

Thanks,

        tglx