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!
On Thu 2022-02-17 13:47 +0100, Frederic Weisbecker wrote:
> 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?
Hi Frederic,
Yes - this is exactly it.
> > 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?
If I understand correctly, in the context of nohz_full, since such work is
deferred, it will only be handled in a scenario when the periodic/or
scheduling-clock tick is enabled i.e. the timer was reprogrammed on exit
from idle.
Kind regards,
--
Aaron Tomlin