Messages in this thread | | | Date | Mon, 26 Sep 2022 10:20:04 +0100 | From | Aaron Tomlin <> | Subject | Re: [PATCH v8 5/5] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too |
| |
On Sun 2022-09-25 09:05 +0800, Hillf Danton wrote: > On 24 Sep 2022 16:24:41 +0100 Aaron Tomlin <atomlin@redhat.com> 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?
Hi Hillf,
I'm not sure I understand your question.
In this context, when tick processing is stopped, delayed work is not going to be handled until the CPU exits idle.
Kind regards,
-- Aaron Tomlin
| |