On 24 Sep 2022 16:24:41 +0100 Aaron Tomlin <atomlin@xxxxxxxxxx> wrote: > > In the context of the idle task and an adaptive-tick mode/or 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. > > 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. Why did housekeeping CPUs fail to do their works, with this assumption put aside? > [ log message of > [PATCH v8 3/5] mm/vmstat: Do not queue vmstat_update if tick is stopped > > From the vmstat shepherd, for CPUs that have the tick stopped, do not > queue local work to flush the per-CPU vmstats, since in that case the > flush is performed on return to userspace or when entering idle. > Also cancel any delayed work on the local CPU, when entering idle on nohz > full CPUs. Per-CPU pages can be freed remotely from housekeeping CPUs. > > end of log message]
