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 S1752420AbbCWJMN (ORCPT <rfc822;w@1wt.eu>);
	Mon, 23 Mar 2015 05:12:13 -0400
Received: from bombadil.infradead.org ([198.137.202.9]:42489 "EHLO
	bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752390AbbCWJMK (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 23 Mar 2015 05:12:10 -0400
Date: Mon, 23 Mar 2015 10:11:52 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
        Ingo Molnar <mingo@kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Preeti U Murthy <preeti@linux.vnet.ibm.com>,
        Morten Rasmussen <Morten.Rasmussen@arm.com>,
        Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>,
        Rik van Riel <riel@redhat.com>, Mike Galbraith <efault@gmx.de>,
        Nicolas Pitre <nicolas.pitre@linaro.org>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Linaro Kernel Mailman List <linaro-kernel@lists.linaro.org>
Subject: Re: [PATCH v10 10/11] sched: add SD_PREFER_SIBLING for SMT level
Message-ID: <20150323091152.GC23123@twins.programming.kicks-ass.net>
References: <1425052454-25797-1-git-send-email-vincent.guittot@linaro.org>
 <1425052454-25797-11-git-send-email-vincent.guittot@linaro.org>
 <20150302115249.GA9875@linux.vnet.ibm.com>
 <CAKfTPtBOYOuB8sj2mMCEsBSZZ+KoSr+bkQLvAKHPTSWTbtzM0g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKfTPtBOYOuB8sj2mMCEsBSZZ+KoSr+bkQLvAKHPTSWTbtzM0g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2012-12-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Mar 03, 2015 at 09:38:11AM +0100, Vincent Guittot wrote:

> > Prefer siblings logic dates back to https://lkml.org/lkml/2009/8/27/210
> > and only used in update_sd_lb_stats() where we have
> >
> > if (child && child->flags & SD_PREFER_SIBLING)
> >          prefer_sibling = 1;
> >
> > However what confuses me is why should we even look at a child domain's
> > flag to balance tasks across the current sched domain? Why cant we just
> > set and use a sd flag at current level than to look at child domain
> > flag?
> 
> Peter,
> have you got some insight about the reason ?

Yeah, because it makes sense that way? ;-)

The we want to move things to the child's sibling, not the parent's
sibling. We further need to have a child for this to make sense.