[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160810140033.GA23798@krava>
Date: Wed, 10 Aug 2016 16:00:33 +0200
From: Jiri Olsa <jolsa@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
Andi Kleen <ak@...ux.intel.com>, x86@...nel.org,
Ingo Molnar <mingo@...nel.org>,
Frank Ramsay <framsay@...hat.com>
Subject: Re: [RFC][PATCH] x86/smp: Fix __max_logical_packages value setup
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
Powered by blists - more mailing lists