Re: [PATCH v2 1/3] timekeeping: Introduce fast accessor to clock tai

From: Steven Rostedt <rostedt@goodmis.org>
To: Kurt Kanzenbach <kurt@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stephen Boyd <sboyd@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Richard Cochran <richardcochran@gmail.com>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] timekeeping: Introduce fast accessor to clock tai
Date: Wed, 27 Apr 2022 13:22:05 -0400	[thread overview]
Message-ID: <20220427132205.386be5e6@gandalf.local.home> (raw)
In-Reply-To: <20220427112759.1cedda69@gandalf.local.home>

On Wed, 27 Apr 2022 11:27:59 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> I'm able to trigger this on x86 64bit too.
> 
> One thing I noticed, is that the two numbers I have (from a different
> trace, but very similar to the above)
> 
> $ printf "%llx\n" 498151194674148935
> 6e9c9df4afd3647
> 
> $ printf "%llx\n" 1651072699280995911
> 16e9c9df4afd3647
> 
> That is, the last nibble either is 0 or 1, causing the change?
> 
> 06e9c9df4afd3647
> 16e9c9df4afd3647
> 
> The numbers are the same except for that last nibble.

And I just realized what the issue is. The ring buffer only allows for 59
bits of timestamp, as there's times it needs to inject a timestamp into the
buffer, which is 16 bytes, and the first 5 bits are meta data, leaving 59
bits for the timestamp. Since no timestamp came close to that before this
timer, everything worked.

Thus, when a full timestamp is injected, it takes off the 5 MSBs of the
timestamp (which took off that 1) and that is what is happening.

I can see if I can play some games to detect this and replace the top 5
bits with the saved timestamp at the head of the sub buffer.

-- Steve