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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 25 Jan 2016 18:42:24 +0100
From:	Michal Hocko <mhocko@...nel.org>
To:	Christoph Lameter <cl@...ux.com>
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 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?

0eb77e988032 ("vmstat: make vmstat_updater deferrable again and
shut down on idle") doesn't talk about any numbers and neither does
39bf6270f524 ("VM statistics: Make timer deferrable").

But even when refresh_cpu_vm_stats is made more effective there would
still be the problem for RT and the work canceling, though. We would
need much more changes to make this RT ready (both timer and WQ code
would need some changes AFAIU).

Unless there is a clear and huge win from doing the vmstat update
deferrable then I think a revert is more appropriate IMHO.
-- 
Michal Hocko
SUSE Labs