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.
