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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 26 Jan 2016 10:25:21 -0600 (CST)
From:	Christoph Lameter <cl@...ux.com>
To:	Michal Hocko <mhocko@...nel.org>
cc:	Mike Galbraith <umgwanakikbuti@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: fast path cycle muncher (vmstat: make vmstat_updater deferrable
 again and shut down on idle)

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.