linux-kernel - Re: [RFC PATCH] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 17 Feb 2022 13:47:29 +0100
From:   Frederic Weisbecker <frederic@...nel.org>
To:     Aaron Tomlin <atomlin@...hat.com>,
        Marcelo Tosatti <mtosatti@...hat.com>,
        Christoph Lameter <cl@...ux.com>
Cc:     tglx@...utronix.de, mingo@...nel.org, atomlin@...mlin.com,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        Phil Auld <pauld@...hat.com>
Subject: Re: [RFC PATCH] tick/sched: Ensure quiet_vmstat() is called when the
 idle tick was stopped too

Hi Aaron,

I fear my blood-brain barrier doesn't let much of mm/ code in, so I'm adding a
few interested people in Cc. Meanwhile a few comments below:


On Thu, Feb 03, 2022 at 09:43:39PM +0000, Aaron Tomlin wrote:
> Hi Frederic,
> 
> If I understand correctly, in the context of the idle task and a nohz_full
> CPU, quiet_vmstat() can be called: before stopping the idle tick, entering
> an idle state and on exit. In particular, for the latter case, when the
> idle task is required to reschedule, the idle tick can remain stopped and
> the timer expiration time endless i.e., KTIME_MAX. Now, indeed before a
> nohz_full CPU enters an idle state, CPU-specific vmstat counters should
> be processed to ensure the respective values have been reset and folded
> into the zone specific vm_stat[]. That being said, it can only occur when:
> the idle tick was previously stopped, and reprogramming of the timer is not
> required.

So, to make sure I understand, the issue is that with nohz_full, we may
well enter into the idle loop with the tick already stopped. We may also
exit from idle without restarting the tick (again only with nohz_full). And
so this can cause the vmstat to not be flushed upon idle entry. Right?

> 
> A customer provided some evidence which indicates that the idle tick was
> stopped; albeit, CPU-specific vmstat counters still remained populated.
> Thus one can only assume quiet_vmstat() was not invoked on return to the
> idle loop.
> 
> Unfortunately, I suspect this divergence might erroneously prevent a
> reclaim attempt by kswapd. If the number of zone specific free pages are
> below their per-cpu drift value then zone_page_state_snapshot() is used to
> compute a more accurate view of the aforementioned statistic.
> Thus any task blocked on the NUMA node specific pfmemalloc_wait queue will
> be unable to make significant progress via direct reclaim unless it is
> killed after being woken up by kswapd (see throttle_direct_reclaim()).
> That being said, eventually reclaim should give up if the conditions are
> correct, no?

Now if quiet_vmstat() isn't called, the vmstat_work should fix this later,
right? Or does that happen too late perhaps?

Thanks!