public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Guenter Roeck <linux@roeck-us.net>, John Stultz <jstultz@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Anna-Maria Behnsen <anna-maria@linutronix.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	Stephen Boyd <sboyd@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [patch 2/2] timekeeping: Always check for negative motion
Date: Fri, 29 Nov 2024 13:16:08 +0100	[thread overview]
Message-ID: <874j3qxmk7.ffs@tglx> (raw)
In-Reply-To: <2cb25f89-50b9-4e72-9b18-bee78e09c57c@roeck-us.net>

On Thu, Nov 28 2024 at 07:30, Guenter Roeck wrote:
> On 11/28/24 06:51, Thomas Gleixner wrote:
> [   19.090000] ###### now: b5ac62 last: d447e38 mask: ffffff return: 712e2a
> [   19.110000] ###### now: b9ebc3 last: db506d0 mask: ffffff return: 4e4f3
> [   19.120000] ###### now: bb842f last: db8d760 mask: ffffff return: 2accf
> [   19.160000] ###### now: c43f2e last: dbabfa8 mask: ffffff return: 97f86
>
> 'last' advances beyond 'mask', and after that the result is always bad. The call to
> clocksource_delta() is from timekeeping_advance().

This does not make any sense. The bits above the mask in cycle_last are
irrelevant:

        delta = (now - last) & mask;

> [    3.350000] ###### now:  6c4f last:  fe6a84 mask: ffffff return: 201cb    <---
> [    3.360000] ###### now: 40427 last: 10052cc mask: ffffff return: 3b15b    <---

       0x40427 - 0x10052cc = 0xffffffffff03b15b
       0xffffffffff03b15b & 0xffffff = 0x3b15b

That's not any different than before. The only difference is that the
return value is checked:

       return delta & ~(mask >> 1) ? 0 : delta;

But clearly none of the resulting deltas (after masking) has bit 23
set. So the function can't return 0, right?

Coming back to my earlier assumption vs. the max idle time. Here is a
long idle sleep:

> [   18.500000] ###### now: 45b0a2 last: d1c7050 mask: ffffff return: 294052
> [   19.090000] ###### now: b5ac62 last: d447e38 mask: ffffff return: 712e2a

The cycle interval is 125000 clock cycles per tick. That's a HZ=100
kernel, so the nominal clock frequency is 12.5 MHz.

  0x712e2a/12.5e6 = 0.593391s

which is close to the 597268854ns max_idle_ns value.

That's about 0.0776978s away from the point where the delta becomes >
mask/2. So there is a valid concern vs. these long idle sleeps on
machines with a small counter width.

But none of this explains the problems you are observing.

Can you instrument clocksource_delta() to print the values only when the
negative motion detection triggers?

         if (delta & ~(mask >> 1))
         	pr_info(....);

Thanks,

        tglx

  reply	other threads:[~2024-11-29 12:16 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-31 12:04 [patch 0/2] timekeeping: Fall cleaning Thomas Gleixner
2024-10-31 12:04 ` [patch 1/2] timekeeping: Remove CONFIG_DEBUG_TIMEKEEPING Thomas Gleixner
2024-11-02  4:14   ` John Stultz
2024-11-02  9:24   ` [tip: timers/core] " tip-bot2 for Thomas Gleixner
2024-10-31 12:04 ` [patch 2/2] timekeeping: Always check for negative motion Thomas Gleixner
2024-11-02  4:15   ` John Stultz
2024-11-02  9:24   ` [tip: timers/core] " tip-bot2 for Thomas Gleixner
2024-11-25  0:48   ` [patch 2/2] " Guenter Roeck
2024-11-27 22:08     ` John Stultz
2024-11-27 23:02       ` Guenter Roeck
2024-11-28 14:51         ` Thomas Gleixner
2024-11-28 15:30           ` Guenter Roeck
2024-11-29 12:16             ` Thomas Gleixner [this message]
2024-11-29 16:09               ` Guenter Roeck
2024-11-30 11:09                 ` Thomas Gleixner
2024-11-30 18:21                   ` Guenter Roeck
2024-12-03 10:16                     ` [patch] clocksource: Make negative motion detection more robust Thomas Gleixner
2024-12-05 15:11                       ` [tip: timers/urgent] " tip-bot2 for Thomas Gleixner
2024-11-28 15:57           ` [patch 2/2] timekeeping: Always check for negative motion Guenter Roeck
2024-11-28 17:13             ` Guenter Roeck
2024-11-28 17:47               ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874j3qxmk7.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=anna-maria@linutronix.de \
    --cc=frederic@kernel.org \
    --cc=jstultz@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=peterz@infradead.org \
    --cc=sboyd@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox