Date:   Tue, 31 Jan 2023 20:59:05 +0100
From:   Peter Zijlstra <peterz@infradead.org>
To:     Alexey Dobriyan <adobriyan@gmail.com>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Yu Liao <liaoyu15@huawei.com>, fweisbec@gmail.com,
        mingo@kernel.org, liwei391@huawei.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: <Y9lzCaC2k/Un64O3@hirez.programming.kicks-ass.net>
References: <20230128020051.2328465-1-liaoyu15@huawei.com>
 <87357q228f.ffs@tglx>
 <Y9lfe54aoCWlmyqy@p183>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y9lfe54aoCWlmyqy@p183>
Precedence: bulk

On Tue, Jan 31, 2023 at 09:35:39PM +0300, Alexey Dobriyan wrote:

> > Seriously this procfs accuracy is the least of the problems and if this
> > would be the only issue then we could trivially fix it by declaring that
> > the procfs output might go backwards.
> 
> Declarations on l-k are meaningless.

Not really, we often do the -EWONTFIX thing.

> > If there would be a real reason to ensure monotonicity there then we could
> > easily do that in the readout code.
> 
> People expect it to be monotonic. I wrote this test fully expecting
> that /proc/uptime is monotonic. It didn't ever occured to me that
> idletime can go backwards (nor uptime, but uptime is not buggy).

People want ponies too -- people will just have to cope with not having
ponies.