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 S1756295AbcIFNoK (ORCPT <rfc822;w@1wt.eu>);
        Tue, 6 Sep 2016 09:44:10 -0400
Received: from mail-wm0-f67.google.com ([74.125.82.67]:35108 "EHLO
        mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1755397AbcIFNoG (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 6 Sep 2016 09:44:06 -0400
Message-ID: <1473169443.32128.23.camel@gmail.com>
Subject: Re: [v2 patch v3.18+ regression fix] sched: Further improve
 spurious CPU_IDLE active migrations
From: Mike Galbraith <umgwanakikbuti@gmail.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
        LKML <linux-kernel@vger.kernel.org>, Rik van Riel <riel@redhat.com>
Date: Tue, 06 Sep 2016 15:44:03 +0200
In-Reply-To: <1473167264.32128.5.camel@gmail.com>
References: <1472535775.3960.3.camel@suse.de>
         <20160831100117.GV10121@twins.programming.kicks-ass.net>
         <1472638699.3942.14.camel@suse.de> <1472639782.3942.27.camel@gmail.com>
         <CAKfTPtDjrXnpVGat+avYrER7gKFurQLF_PB1Vt2Nu1dKy2o8aQ@mail.gmail.com>
         <1472703062.3979.60.camel@gmail.com>
         <CAKfTPtDxTH62HGrze+rSrw9+kZc6xHSfJemhWqxhyhLZzM0qDg@mail.gmail.com>
         <1473092813.4412.6.camel@gmail.com> <20160906130127.GA21960@vingu-laptop>
         <1473167264.32128.5.camel@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
X-Mailer: Evolution 3.16.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
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-09-06 at 15:07 +0200, Mike Galbraith wrote:
> On Tue, 2016-09-06 at 15:01 +0200, Vincent Guittot wrote:
> > Le Monday 05 Sep 2016 à 18:26:53 (+0200), Mike Galbraith a écrit :
> > > Coming back to this, how about this instead, only increase the
> > > group
> > > imbalance threshold when sd_llc_size == 2.  Newer L3 equipped
> > > processors then aren't affected.
> > > 
> > 
> > Not sure that all systems with sd_llc_size == 2 wants this
> > behavior.
> > 
> > Why not adding a sched_feature for changing the 2nd half of the
> > test
> > for some systems ?
> 
> Because users won't know, and shouldn't need to know that they need to
> flip that switch.

The patchlet just puts these CPUs back in the same boat they were in
before Rik's patch landed.  Also, if people are doing serious compute,
they're unlikely to leave any placement decisions up to the scheduler.

	-Mike