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 S1752197AbcAZTJv (ORCPT <rfc822;w@1wt.eu>);
	Tue, 26 Jan 2016 14:09:51 -0500
Received: from mail-wm0-f50.google.com ([74.125.82.50]:36963 "EHLO
	mail-wm0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751103AbcAZTJs (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Jan 2016 14:09:48 -0500
Message-ID: <1453835384.3534.84.camel@gmail.com>
Subject: Re: fast path cycle muncher (vmstat: make vmstat_updater deferrable
 again and shut down on idle)
From: Mike Galbraith <umgwanakikbuti@gmail.com>
To: Christoph Lameter <cl@linux.com>
Cc: Michal Hocko <mhocko@kernel.org>, Peter Zijlstra <peterz@infradead.org>,
        LKML <linux-kernel@vger.kernel.org>
Date: Tue, 26 Jan 2016 20:09:44 +0100
In-Reply-To: <alpine.DEB.2.20.1601261222020.1964@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>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.16.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, 2016-01-26 at 12:22 -0600, Christoph Lameter wrote:
> On Tue, 26 Jan 2016, Mike Galbraith wrote:
> 
> > On Tue, 2016-01-26 at 10:26 -0600, Christoph Lameter wrote:
> > > On Tue, 26 Jan 2016, Mike Galbraith wrote:
> > > 
> > > > > 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.
> > > 
> > > Whats the point of going idle if you have things to do soon?
> > 
> > When a task schedules off, how do you know it'll be back at all,
> > much
> > less soon?
> 
> 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?

	-Mike