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 S1752634AbcFBDcl (ORCPT <rfc822;w@1wt.eu>);
	Wed, 1 Jun 2016 23:32:41 -0400
Received: from mga09.intel.com ([134.134.136.24]:3292 "EHLO mga09.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752219AbcFBDcj (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 1 Jun 2016 23:32:39 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.26,404,1459839600"; 
   d="scan'208";a="979169661"
Date: Thu, 2 Jun 2016 03:35:24 +0800
From: Yuyang Du <yuyang.du@intel.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Mike Galbraith <umgwanakikbuti@gmail.com>,
        Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Benjamin Segall <bsegall@google.com>, Paul Turner <pjt@google.com>,
        Morten Rasmussen <morten.rasmussen@arm.com>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>
Subject: Re: [RFC PATCH 1/2] sched: Clean up SD_BALANCE_WAKE flags in sched
 domain build-up
Message-ID: <20160601193524.GZ18670@intel.com>
References: <1464657098-24880-1-git-send-email-yuyang.du@intel.com>
 <1464657098-24880-2-git-send-email-yuyang.du@intel.com>
 <20160531092146.GT3192@twins.programming.kicks-ass.net>
 <20160531013132.GQ18670@intel.com>
 <1464757633.4023.39.camel@gmail.com>
 <20160601000105.GU18670@intel.com>
 <CAKfTPtBig+kRVeOoYqhoa1GRXzbjMKmR8ODgAGZr0Jcm-YZncQ@mail.gmail.com>
 <20160601010311.GV18670@intel.com>
 <CAKfTPtCH9ycaTfK383b6DqE7JSOwz_e4Xr46S+XF5ZGVE4+_Jg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKfTPtCH9ycaTfK383b6DqE7JSOwz_e4Xr46S+XF5ZGVE4+_Jg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Jun 01, 2016 at 11:24:45AM +0200, Vincent Guittot wrote:
> >
> > So with the patch, we will have a little bit semantic change, SD_BALANCE_WAKE
> > implies SD_WAKE_AFFINE if allowed, and will favor "fast path" if possible. I don't
> > think we should do anything otherwise.
> 
> Why should we not do anything else ?
> 
> The current default configuration is to only use the wake_affine path.
> With your changes, the default configuration will try to use wake
> affine and will fall back to long load balance sequence if wake affine
> doesn't find a sched_domain
> 
> That's a major changes in the behavior
 
Well, I won't argue that this hasn't changed, but I'd argue that this change
isn't a bad change: (a) it restores the flags to their meanings and makes them
more "elegant", (b) we definitely need further work to improve
select_task_rq_fair(), there has already been a comment marked XXX, right? :)