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 S1753340AbbGIICH (ORCPT <rfc822;w@1wt.eu>);
	Thu, 9 Jul 2015 04:02:07 -0400
Received: from mail-wi0-f182.google.com ([209.85.212.182]:34275 "EHLO
	mail-wi0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751236AbbGIIB4 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 9 Jul 2015 04:01:56 -0400
Date: Thu, 9 Jul 2015 10:01:51 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Rik van Riel <riel@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
        linux-kernel@vger.kernel.org, Mel Gorman <mgorman@suse.de>
Subject: Re: [PATCH] sched/numa: Restore sched feature NUMA to its earlier
 avatar.
Message-ID: <20150709080151.GA31669@gmail.com>
References: <1436361633-4970-1-git-send-email-srikar@linux.vnet.ibm.com>
 <20150708135644.GC23380@gmail.com>
 <559D4128.2080606@redhat.com>
 <20150709062926.GA31232@gmail.com>
 <20150709065746.GE26095@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150709065746.GE26095@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Srikar Dronamraju <srikar@linux.vnet.ibm.com> wrote:

> > So I find the patch, the description and the comments in the code conflicting and 
> > confusing.
> > 
> > The patch does this:
> > 
> > @@ -5676,10 +5676,10 @@ static int migrate_degrades_locality(struct task_struct *p, struct lb_env *env)
> >         unsigned long src_faults, dst_faults;
> >         int src_nid, dst_nid;
> > 
> > -       if (!p->numa_faults || !(env->sd->flags & SD_NUMA))
> > +       if (!sched_feat(NUMA) || !sched_feat(NUMA_FAVOUR_HIGHER))
> >                 return -1;
> > 
> > -       if (!sched_feat(NUMA))
> > +       if (!p->numa_faults || !(env->sd->flags & SD_NUMA))
> >                 return -1;
> > 
> >         src_nid = cpu_to_node(env->src_cpu);
> > 
> > 
> > while the default for 'NUMA' is 0, 'NUMA_FAVOUR_HIGHER' is 1.
> > 
> > Which in itself is confusing: WTH do we have a generic switch called 'NUMA' and 
> > then have it disabled?
> 
> NUMA feature gets enabled on multi-node boxes because of
> 
> start_kernel() -> numa_policy_init() -> check_numabalancing_enable() ->
>  set_numabalancing_state() -> sched_feat_set("NUMA");

Ugh, that is nonsensical!

If CONFIG_SCHED_DEBUG is disabled then sched_features is a constant value:

  # define const_debug const

  ...

  extern const_debug unsigned int sysctl_sched_features;

sched_features are _only_ meant for debugging. They turn into an unchangeable set 
of features when SCHED_DEBUG is disabled - and that is very much by design.

The whole set_numabalancing_state() muck needs to be fixed.

Thanks,

	Ingo