lkml.org 
[lkml]   [2021]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v10 clocksource 3/7] clocksource: Check per-CPU clock synchronization when marked unstable
Date
On Sun, Apr 25 2021 at 21:12, Andi Kleen wrote:

> On Sun, Apr 25, 2021 at 03:47:04PM -0700, Paul E. McKenney wrote:
>> Some sorts of per-CPU clock sources have a history of going out of
>> synchronization with each other. However, this problem has purportedy
>> been solved in the past ten years. Except that it is all too possible
>> that the problem has instead simply been made less likely, which might
>> mean that some of the occasional "Marking clocksource 'tsc' as unstable"
>> messages might be due to desynchronization. How would anyone know?
>>
>> Therefore apply CPU-to-CPU synchronization checking to newly unstable
>> clocksource that are marked with the new CLOCK_SOURCE_VERIFY_PERCPU flag.
>> Lists of desynchronized CPUs are printed, with the caveat that if it
>> is the reporting CPU that is itself desynchronized, it will appear that
>> all the other clocks are wrong. Just like in real life.
>
> Well I could see this causing a gigantic flood of messages then.
> Assume I have 300 cores, do I get all those messages 300 times repeated
> then? If the console is slow this might end up taking a lot
> of CPU time.

Exactly 4 pr_warn() lines in dmesg which are emitted exactly once when
the TSC deviates from the watchdog where three of them print a cpumask
are really a gigantic flood of messsages.

Thanks,

tglx

\
 
 \ /
  Last update: 2021-04-26 09:19    [W:0.097 / U:1.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site