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 S1752378AbcHQN7Z (ORCPT <rfc822;w@1wt.eu>);
	Wed, 17 Aug 2016 09:59:25 -0400
Received: from mail-yb0-f196.google.com ([209.85.213.196]:34437 "EHLO
	mail-yb0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752027AbcHQN7X (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 17 Aug 2016 09:59:23 -0400
Date: Wed, 17 Aug 2016 09:58:55 -0400
From: Tejun Heo <tj@kernel.org>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>, Ming Lei <tom.leiming@gmail.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>,
        Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Lai Jiangshan <laijs@cn.fujitsu.com>,
        Michael Holzheu <holzheu@linux.vnet.ibm.com>,
        Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [bisected] "sched: Allow per-cpu kernel threads to run on online
 && !active" causes warning
Message-ID: <20160817135855.GH9516@htj.duckdns.org>
References: <alpine.DEB.2.11.1607271717320.19896@nanos>
 <20160730112552.GA3744@osiris>
 <CACVXFVNrMjk46pB_E=5fQP2njN8cntSKJ_BMnR-Z4ZmxsMpqyg@mail.gmail.com>
 <20160815111908.GA3903@osiris>
 <20160815224801.GA3672@mtj.duckdns.org>
 <20160816075505.GB3896@osiris>
 <20160816152027.GD9516@htj.duckdns.org>
 <20160816152949.GL30192@twins.programming.kicks-ass.net>
 <20160816154205.GE9516@htj.duckdns.org>
 <20160816221953.GA3373@osiris>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160816221953.GA3373@osiris>
User-Agent: Mutt/1.6.2 (2016-07-01)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hello, Heiko.

On Wed, Aug 17, 2016 at 12:19:53AM +0200, Heiko Carstens wrote:
> I think the easiest solution would be to simply assign all cpus, for which
> we do not have any topology information, to an arbitrary node; e.g. round
> robin.
> 
> After all the case that cpus are added later is rare and the s390 fake numa
> implementation does not know about the memory topology. All it is doing is

Ah, okay, so there really is no requirement for a newly coming up cpu
to be on a specific node.

> distributing the memory to several nodes in order to avoid a single huge
> node. So that should be sort of ok.

Sounds good to me.  If that's the only purpose, we don't lose much by
round-robining the possible CPUs on boot and sticking with the
mapping.

Thanks.

-- 
tejun