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

From: Marcelo Tosatti
Date: Mon Apr 25 2022 - 15:22:41 EST


On Mon, Apr 25, 2022 at 03:17:17PM +0100, Aaron Tomlin wrote:
> On Mon 2022-04-25 15:27 +0200, Peter Zijlstra wrote:
> > On Mon, Apr 25, 2022 at 02:09:06PM +0200, Christoph Lameter wrote:
> > > On Mon, 25 Apr 2022, Aaron Tomlin wrote:
> > >
> > > > Yes, in the context of nohz, this patch should ensure it, if required, when
> > > > the idle tick is to be stopped.
> > >
> > > What I said was that it is generally useful. Even in the non NOHZ case.
> > >
> > > Folding the vmstat diffs *always* when entering idle prevents unnecessary
> > > wakeups and processing in the future and also provides more accurate
> > > counters for the VM allowing better decision to be made on reclaim.
> >
> > I'm thinking you're going to find a ton of regressions if you try it
> > though; some workloads go idle *very* shortly, doing all this accounting
> > is going to be counter-productive.
>
> Hi Peter, Christoph,
>
> Indeed. Which was why I decided, initially, against the general-purpose
> case/or approach. Personally, I would prefer to keep this somewhat
> restrictive to nohz.

Is there anything that prevents a nohz full CPU from running an
application with short and frequent idling?

Note:

commit a5183862e76fdc25f36b39c2489b816a5c66e2e5
Author: Yunfeng Ye <yeyunfeng@xxxxxxxxxx>
Date: Thu May 13 01:29:16 2021 +0200

tick/nohz: Conditionally restart tick on idle exit

In nohz_full mode, switching from idle to a task will unconditionally
issue a tick restart. If the task is alone in the runqueue or is the
highest priority, the tick will fire once then eventually stop. But that
alone is still undesired noise.

Therefore, only restart the tick on idle exit when it's strictly
necessary.

Signed-off-by: Yunfeng Ye <yeyunfeng@xxxxxxxxxx>
Signed-off-by: Frederic Weisbecker <frederic@xxxxxxxxxx>
Signed-off-by: Ingo Molnar <mingo@xxxxxxxxxx>
Acked-by: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Link: https://lore.kernel.org/r/20210512232924.150322-3-frederic@xxxxxxxxxx