Re: [PATCH v3 3/4] clocksource: Dynamically increase watchdog_max_skew

[Feng Tang]

Hi Waiman,

On Mon, Nov 22, 2021 at 01:27:25PM -0500, Waiman Long wrote:
> 
> On 11/22/21 00:02, Feng Tang wrote:
> > On Thu, Nov 18, 2021 at 02:14:38PM -0500, Waiman Long wrote:
> > > It is possible that a long-lasting intensive workload running on
> > > a system may cause the clock skew test to be skipped for extended
> > > period of time. One way to avoid this is to dynamically increase the
> > > watchdog_max_skew used in the clock skew test.
> > > 
> > > However, we also don't want watchdog_max_skew to be continuously increased
> > > without bound. So we limit the increase up to 10*WATCHDOG_MAX_SKEW. If
> > > that happens, there is something wrong the current watchdog and we are
> > > going to mark it as unstable and select a new watchdog, if possible.
> > For reselecting watchdog, in these cases, I think it's the extreme system
> > stress causing the MMIO read of hpet to be slow (plus some lock), fallback
> > to other watchdog whose read is MMIO or ioport may not help much. I tried
> > this patch, and when "acpi_pm" timer is used instead of "hpet", similar
> > thing can still happen.
> 
> Yes, I am aware of that. Switching to acpi_pm, did not reduce the
> consecutive read delay. However, the current limit for this watchdog
> fallback is when the delay exceed 5*WATCHDOG_MAX_SKEW. With a default of
> 100us, that mean 500us which is a really large delay that maybe there is
> something wrong with the hpet timer. Of course, the selection of this limit
> is kind of arbitrary. If you have concern about that, we can leave this
> patch out.

I'm not against the "watchdog_max_skew" concept, just wanted to stat
the hpet may be innocent in the case.

I don't have strong opinion about reselecting watchdog either. If the 
server is always running that intensive workload, the watchog could
be fallback to other clocksource, then eventually to NULL device,
which is not bad for that specific case.

Thanks,
Feng

> Cheers,
> Longman