From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938747AbcHJSqq (ORCPT ); Wed, 10 Aug 2016 14:46:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40338 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S938726AbcHJSqd (ORCPT ); Wed, 10 Aug 2016 14:46:33 -0400 Date: Wed, 10 Aug 2016 16:00:33 +0200 From: Jiri Olsa To: Peter Zijlstra Cc: Thomas Gleixner , Andi Kleen , linux-kernel@vger.kernel.org, Andi Kleen , x86@kernel.org, Ingo Molnar , Frank Ramsay Subject: Re: [RFC][PATCH] x86/smp: Fix __max_logical_packages value setup Message-ID: <20160810140033.GA23798@krava> References: <20160803162358.GA10890@krava> <20160810135417.GP30192@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160810135417.GP30192@twins.programming.kicks-ass.net> User-Agent: Mutt/1.6.2 (2016-07-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 10 Aug 2016 14:00:36 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 10, 2016 at 03:54:17PM +0200, Peter Zijlstra wrote: > On Wed, Aug 03, 2016 at 06:23:58PM +0200, Jiri Olsa wrote: SNIP > > --- > > diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c > > index 157bf0957219..484f7d357c77 100644 > > --- a/arch/x86/kernel/smpboot.c > > +++ b/arch/x86/kernel/smpboot.c > > @@ -340,7 +340,7 @@ static void __init smp_init_package_map(void) > > ncpus = 1; > > } > > > > - __max_logical_packages = DIV_ROUND_UP(total_cpus, ncpus); > > + __max_logical_packages = total_cpus; > > This seems undesirable.. it would grow the bitmap unnecessarily big on > most setups. > > Is there no way to detect the brain damage inflicted by that BIOS option > and fudge ncpus in that case? yea, I have no idea.. that's why this is RFC ;-) maybe we could also gradually allocate this bitmap in topology_update_package_map.. I'll check on that jirka