On Mon, 2016-01-25 at 12:02 -0600, Christoph Lameter wrote:
> On Mon, 25 Jan 2016, Michal Hocko wrote:
>
> > On Sat 23-01-16 17:21:55, Mike Galbraith wrote:
> > > Hi Christoph,
> > >
> > > While you're fixing that commit up, can you perhaps find a better home
> > > for quiet_vmstat()? It not only munches cycles when switching cross
> > > -core mightily, for -rt it injects a sleeping lock into the idle task.
> > >
> > > 12.89% [kernel] [k] refresh_cpu_vm_stats.isra.12
> > > 4.75% [kernel] [k] __schedule
> > > 4.70% [kernel] [k] mutex_unlock
> > > 3.14% [kernel] [k] __switch_to
> >
> > Hmm, I wouldn't have expected that refresh_cpu_vm_stats could have
> > such a large footprint. I guess this would be just an expensive noop
> > because we have to check all the zones*counters and do an expensive
> > this_cpu_xchg. Is the whole deferred thing worth this overhead?
>
> Why would the deferring cause this overhead?
Because we schedule to idle cores aggressively, thus we may pop in and
out of idle at high frequency.
> Also there is no cross core activity from quiet_vmstat(). It simply
> disables the local vmstat updates.
Again, the cross core activity is not due to quiet_vmstat(), it is due
to pipe-test threads running on two cores, and meeting quiet_vmstat()
at high frequency.
> > Unless there is a clear and huge win from doing the vmstat update
> > deferrable then I think a revert is more appropriate IMHO.
>
> 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.
Perf and RT say we don't want quiet_vmstat() in the idle loop either.
-Mike
