From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964792AbcAYRma (ORCPT ); Mon, 25 Jan 2016 12:42:30 -0500 Received: from mail-wm0-f43.google.com ([74.125.82.43]:36710 "EHLO mail-wm0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932788AbcAYRm1 (ORCPT ); Mon, 25 Jan 2016 12:42:27 -0500 Date: Mon, 25 Jan 2016 18:42:24 +0100 From: Michal Hocko To: Christoph Lameter Cc: Mike Galbraith , Peter Zijlstra , LKML Subject: Re: fast path cycle muncher (vmstat: make vmstat_updater deferrable again and shut down on idle) Message-ID: <20160125174224.GH23934@dhcp22.suse.cz> References: <20160121082402.GA29520@dhcp22.suse.cz> <20160121165148.GF29520@dhcp22.suse.cz> <20160122140418.GB19465@dhcp22.suse.cz> <20160122161201.GC19465@dhcp22.suse.cz> <1453566115.3529.8.camel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1453566115.3529.8.camel@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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