From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752878AbcAZTWS (ORCPT <rfc822;w@1wt.eu>);
	Tue, 26 Jan 2016 14:22:18 -0500
Received: from resqmta-ch2-05v.sys.comcast.net ([69.252.207.37]:36668 "EHLO
	resqmta-ch2-05v.sys.comcast.net" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1752838AbcAZTWF (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Jan 2016 14:22:05 -0500
Date: Tue, 26 Jan 2016 13:22:03 -0600 (CST)
From: Christoph Lameter <cl@linux.com>
X-X-Sender: cl@east.gentwo.org
To: Mike Galbraith <umgwanakikbuti@gmail.com>
cc: Michal Hocko <mhocko@kernel.org>, Peter Zijlstra <peterz@infradead.org>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: fast path cycle muncher (vmstat: make vmstat_updater deferrable
 again and shut down on idle)
In-Reply-To: <1453835384.3534.84.camel@gmail.com>
Message-ID: <alpine.DEB.2.20.1601261320310.4156@east.gentwo.org>
References: <alpine.DEB.2.20.1601201552590.26496@east.gentwo.org> <20160121082402.GA29520@dhcp22.suse.cz> <alpine.DEB.2.20.1601210941540.7063@east.gentwo.org> <20160121165148.GF29520@dhcp22.suse.cz> <alpine.DEB.2.20.1601211130580.7741@east.gentwo.org>
 <20160122140418.GB19465@dhcp22.suse.cz> <alpine.DEB.2.20.1601220950290.17929@east.gentwo.org> <20160122161201.GC19465@dhcp22.suse.cz> <alpine.DEB.2.20.1601221046020.17984@east.gentwo.org> <1453566115.3529.8.camel@gmail.com> <20160125174224.GH23934@dhcp22.suse.cz>
 <alpine.DEB.2.20.1601251152290.19487@east.gentwo.org> <1453774465.3642.13.camel@gmail.com> <alpine.DEB.2.20.1601261025320.27957@east.gentwo.org> <1453828136.3534.9.camel@gmail.com> <alpine.DEB.2.20.1601261222020.1964@east.gentwo.org>
 <1453835384.3534.84.camel@gmail.com>
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, 26 Jan 2016, Mike Galbraith wrote:

> > Ok so you are running an artificial benchmark that always gets the
> > system running again when it decides to go idle?
>
> The benchmark does not alter the cycle expenditure per event.  The real
> world will pay the toll less frequently than the artificial benchmark,
> yes, but it will pay nonetheless, and for most, needlessly.  Or?

Well if it does not pay it there then it is going to pay for it later when
the vmstat_updater needs to cause a wakeup to fold the data. Also not
folding the vmstat updates increases the time that minor updates are
deferred and thus impacts the accuracy of the global vm counters. That
seems to have been important recently.