Date:   Wed, 1 Feb 2023 10:03:28 +0100
From:   Peter Zijlstra <peterz@infradead.org>
To:     Frederic Weisbecker <frederic@kernel.org>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Yu Liao <liaoyu15@huawei.com>, fweisbec@gmail.com,
        mingo@kernel.org, liwei391@huawei.com, adobriyan@gmail.com,
        mirsad.todorovac@alu.unizg.hr, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] tick/nohz: fix data races in get_cpu_idle_time_us()
Message-ID: <Y9oq4OSJXJvr56Oj@hirez.programming.kicks-ass.net>
References: <20230128020051.2328465-1-liaoyu15@huawei.com>
 <87357q228f.ffs@tglx>
 <Y9lyx38kHmKEF5CQ@hirez.programming.kicks-ass.net>
 <Y9mEB7LMaZ0dMQS/@lothringen>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y9mEB7LMaZ0dMQS/@lothringen>
Precedence: bulk

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.