[lkml]   [2021]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Regression in posix-cpu-timers.c (was Re: Linux 5.14.4)
On Wed, Sep 15, 2021 at 11:41:42AM -0700, Linus Torvalds wrote:
> On Wed, Sep 15, 2021 at 11:31 AM Frederic Weisbecker
> <> wrote:
> >
> > Right, this should fix the issue:
> Hmm.
> Can you explain why the fix isn't just to revert that original commit?
> It looks like the only real difference is that now it does *extra
> work* with all that tick_nohz_dep_set_signal().
> Isn't it easier to just leave any old timer ticking, and not do the
> extra work until it expires and you notice "ok, it's not important"?
> IOW, that original commit explicitly broke the only case it changed -
> the timer being disabled. So why isn't it just reverted? What is it
> that kleeps us wanting to do the extra work for the disabled timer
> case?
> As long as it's fixed, I'm all ok with this, but I'm looking at the
> commit message for that broken commit, and I'm looking at the commit
> message for the fix, and I'm not seeing an actual _explanation_ for
> this churn.

The commit indeed failed to explain correctly the actual issue.

When a process wide posix cpu timer (eg: itimer) is elapsing, all the
threads inside that process contend on their cputime updates
(account_group_user_time() and account_group_system_time())

The overhead just consists in concurrent atomic64_add() calls on
every tick but still... And this can remain for a very long while,
until the previous value of the timer expiry is reached.

The other symptom, more of a corner case for most, is that the CPUs
running any thread of that process won't be able to enter in nohz_full
mode, again until the old timer expiry is reached.

 \ /
  Last update: 2021-09-15 23:17    [W:0.063 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site