From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1945896AbcHRJbC (ORCPT ); Thu, 18 Aug 2016 05:31:02 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:63319 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753135AbcHRJbA (ORCPT ); Thu, 18 Aug 2016 05:31:00 -0400 X-IBM-Helo: d06dlp01.portsmouth.uk.ibm.com X-IBM-MailFrom: holzheu@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Thu, 18 Aug 2016 11:30:51 +0200 From: Michael Holzheu To: Tejun Heo Cc: Heiko Carstens , Peter Zijlstra , Ming Lei , Thomas Gleixner , LKML , Yasuaki Ishimatsu , Andrew Morton , Lai Jiangshan , Martin Schwidefsky Subject: Re: [bisected] "sched: Allow per-cpu kernel threads to run on online && !active" causes warning In-Reply-To: <20160817135855.GH9516@htj.duckdns.org> References: <20160730112552.GA3744@osiris> <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> <20160817135855.GH9516@htj.duckdns.org> Organization: IBM X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16081809-0040-0000-0000-00000214A550 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16081809-0041-0000-0000-00002165ED49 Message-Id: <20160818113051.10cdab65@TP-holzheu> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-08-18_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608180110 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Wed, 17 Aug 2016 09:58:55 -0400 schrieb Tejun Heo : > 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. Well, "no requirement" this is not 100% correct. Currently we use the CPU topology information to assign newly coming CPUs to the "best fitting" node. Example: 1) We have we two fake NUMA nodes N1 and N2 with the following CPU assignment: - N1: cpu 1 on chip 1 - N2: cpu 2 on chip 2 2) A new cpu 3 is configured that lives on chip 2 3) We assign cpu 3 to N2 We do this only if the nodes are balanced. If N2 had already one more cpu than N1 we would assign the new cpu to N1. Michael