Re: fast path cycle muncher (vmstat: make vmstat_updater deferrable again and shut down on idle)

[Christoph Lameter]

On Mon, 25 Jan 2016, Michal Hocko wrote:

> > Why would the deferring cause this overhead?
>
> I guess the profile speaks for itself, doesn't it?

But the system is going idle? Why would this impact performance?

> > Also there is no cross core activity from quiet_vmstat(). It simply
> > disables the local vmstat updates.
>
> It doesn't go cross core but it still does nr_zones * counters atomic
> ops.

If there are updates then yes.

> > It reduces the OS events that the application experiences by folding it
> > into the tick events. If its not deferrable then a timer event will be
> > generated in addition to the tick. We do not want that.
>
> Yes this is what I have read in the changelog. But "how much" part is
> really missing. Is this even quantifiable?

Oh yes. If you want to have low latency responses yes. And event like that
causes a couple of microseconds delay which will cause a moneytary impact
if you have to react to stock trading events.

> Maybe this overhead can be reduced by outsourcing the functionality to
> vmstat_shepherd which can check idle CPUs, cancel the timer for them
> update the differentials and put them to cpu_stat_off?

Remote updating of differentials is problematic due to the counters being
per cpu values that are expected to only be updated from the cpu that
"owns" them.

> > The regression that I know of (independent of "RT") is due as far as I
> > know due to the switch of the parameters of some vmstat functions to 64
> > bit instead of 32 bit.
>
> I am not sure I am following.

An additional patch was merged for 4.5 that increases the arguments to the
counter operations to 64 bit which is known for regressions.