Message-ID: <e0a41ba0-59d6-d320-02b0-37534f9e66a5@redhat.com>
Date:   Mon, 22 Nov 2021 13:27:25 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.2.0
Subject: Re: [PATCH v3 3/4] clocksource: Dynamically increase
 watchdog_max_skew
Content-Language: en-US
To:     Feng Tang <feng.tang@intel.com>
Cc:     John Stultz <john.stultz@linaro.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Stephen Boyd <sboyd@kernel.org>,
        "Paul E. McKenney" <paulmck@kernel.org>,
        linux-kernel@vger.kernel.org,
        Peter Zijlstra <peterz@infradead.org>,
        Cassio Neri <cassio.neri@gmail.com>,
        Linus Walleij <linus.walleij@linaro.org>,
        Frederic Weisbecker <frederic@kernel.org>
References: <20211118191439.1000012-1-longman@redhat.com>
 <20211118191439.1000012-4-longman@redhat.com>
 <20211122050224.GH34844@shbuild999.sh.intel.com>
From:   Waiman Long <longman@redhat.com>
In-Reply-To: <20211122050224.GH34844@shbuild999.sh.intel.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


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.

Cheers,
Longman