[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y9oq4OSJXJvr56Oj@hirez.programming.kicks-ass.net>
Date: Wed, 1 Feb 2023 10:03:28 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Frederic Weisbecker <frederic@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Yu Liao <liaoyu15@...wei.com>, fweisbec@...il.com,
mingo@...nel.org, liwei391@...wei.com, adobriyan@...il.com,
mirsad.todorovac@....unizg.hr, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] tick/nohz: fix data races in get_cpu_idle_time_us()
On Tue, Jan 31, 2023 at 10:11:35PM +0100, Frederic Weisbecker wrote:
> On Tue, Jan 31, 2023 at 08:57:59PM +0100, Peter Zijlstra wrote:
> > On Tue, Jan 31, 2023 at 03:44:00PM +0100, Thomas Gleixner wrote:
> >
> > > P.S.: I hate the spinlock in the idle code path, but I don't have a
> > > better idea.
> >
> > seqcount? It would avoid the obvious interleave and put most of the onus
> > on the reader (which never happens anyway).
>
> Yep, and do the update locally only on idle exit. But note that neither
> seqcount nor spinlock will fix the nr_iowait_cpu() based thing. This counter
> can be decremented remotely even during the idle period so the reader
> can see an iowait period that may eventually be accounted as !iowait,
> or the reverse. Breaking the monotonicity and even coherency.
>
> That stuff is broken by design and this is the reason why it got never
> really fixed. The seqcount/spinlock would make it just a bit less worse.
Yeah, iowait is a random number generator, -EWONTFIX on that.
Powered by blists - more mailing lists