Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
In-Reply-To: <20181112185651.17138-1-mzhivich@akamai.com>
References: <20181112185651.17138-1-mzhivich@akamai.com>
From:   John Stultz <john.stultz@linaro.org>
Date:   Mon, 12 Nov 2018 14:23:37 -0800
Message-ID: <CALAqxLVCwWATXruj+PAAtKMuE4TDCgHCeQAmpz39k33xFm_68Q@mail.gmail.com>
Subject: Re: [PATCH] Revert "clocksource: Make clocksource validation work for
 all clocksources"
To:     Michael Zhivich <mzhivich@akamai.com>
Cc:     lkml <linux-kernel@vger.kernel.org>,
        Ondrej Mosnacek <omosnace@redhat.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Jason Wessel <jason.wessel@windriver.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Nov 12, 2018 at 10:56 AM, Michael Zhivich <mzhivich@akamai.com> wrote:
> Revert commit 1f45f1f33c8c ("clocksource: Make clocksource validation work
> for all clocksources") to restore correct clocksource_delta() computation
> for clocksources that wrap frequently, while retaining the check for tsc
> drifting.
>
> Truncating result of clocksource_delta() to 0 causes incorrect behavior for
> clocksources that wrap frequently (e.g. acpi_pm which is only 24-bit wide).
> In particular, large time deltas (e.g. last = 0x000000, now = 0x800000)
> will be incorrectly computed as 0.
>
> If acpi_pm is used as the clocksource watchdog, and machine is under heavy
> load, the time period for the watchdog check may be significantly longer
> than the requested 0.5 seconds.  If the watchdog check is delayed by 2
> seconds (observed behavior), then acpi_pm time delta will be
>
>         2.5 sec * 3579545 ticks/sec = 8948863 = 0x888c3f
>
> which will be treated as negative and truncated to 0.  This behavior will
> cause tsc to be incorrectly declared unstable in clocksource_watchdog(), as
> it no longer agrees with acpi_pm.

Thanks for raising this issue and submitting the patch!

Yea, this is a concern particularly with quick wrapping clocksources.
Though I worry that if you're already blocking the watchdog from
running for 2.5 seconds, you're likely to also block the watchdog for
more then 5 seconds, which if I'm remembering would result in the same
problem?  In other words, does this really solve the problem, or does
it just push the bar a little further out?

So, I'm wondering to really fix this, do we need to find some way to
raise the priority of the clocksource watchdog, so it isn't deferred
for quite so long?

thanks
-john