From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751055AbcEJGvj (ORCPT ); Tue, 10 May 2016 02:51:39 -0400 Received: from merlin.infradead.org ([205.233.59.134]:58028 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750741AbcEJGvi (ORCPT ); Tue, 10 May 2016 02:51:38 -0400 Date: Tue, 10 May 2016 08:51:33 +0200 From: Peter Zijlstra To: Thomas Gleixner Cc: Josef Bacik , LKML , kernel-team , x86@kernel.org, Kan Liang Subject: Re: Regression introduced by cf6d445f68974d0b15a14cf6021be38a91f2b5d8 Message-ID: <20160510065133.GF3408@twins.programming.kicks-ass.net> References: <761b4a2a-0332-7954-f030-c6639f949612@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 09, 2016 at 09:48:18PM +0200, Thomas Gleixner wrote: > So that explains the wreckage you are seing. We have two options to deal with > this: > > 1) Make intel_num_cpu_cores() a NOOP for SMP=n, so x86_max_cores = 1 This I think; because: > > 2) Make detect_extended_topology() functional for SMP=n, so the real number of > cores is detected UP has no business 'knowing' anything about cores/threads and general topology stuff.