lkml.org 
[lkml]   [2021]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v2 0/4] clocksource: Avoid incorrect hpet fallback
From

On 11/17/21 16:25, Paul E. McKenney wrote:
> On Wed, Nov 17, 2021 at 01:51:51PM -0500, Waiman Long wrote:
>> On 11/17/21 11:54, Paul E. McKenney wrote:
>>> On Tue, Nov 16, 2021 at 06:44:22PM -0500, Waiman Long wrote:
>>> A few questions:
>>>
>>> 1. Once you have all the patches in place, is the increase in
>>> WATCHDOG_MAX_SKEW from 50us to 100us necessary?
>> I think so. Using Feng's reproducer, I was able to cause a hpet-hpet delay
>> of more than 90us on a 1-socket system. With a default 50us
>> WATCHDOG_MAX_SKEW, the chance of a warning showing up will be much higher.
>> Trying to minimize the chance that a warning may appear is my primary reason
>> to increase WATCHDOG_MAX_SKEW.
> Should we downgrade the "had to retry read" complain to pr_info(),
> and make the only real warning be the case where a large number of
> consecutive read attempts fail? I believe that Heiner Kallweit was
> looking for something like this.
Sure. I will downgrade it to pr_info().
>
>>> 2. The reason for having cs->uncertainty_margin set to
>>> 2*WATCHDOG_MAX_SKEW was to allow for worst-case skew from both
>>> the previous and the current reading. Are you sure that
>>> dropping back to WATCHDOG_MAX_SKEW avoids false positives?
>> I can remove the hunk of changing cs->uncertainty_margin. It is critical for
>> this patch.
> Assuming "not critical", good!

Yes, it is "not critical". Somehow I missed the "not" :-)

Cheers,
Longman

\
 
 \ /
  Last update: 2021-11-17 22:57    [W:0.064 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site