linux-kernel - Re: Question about num_possible_cpus() and cpu_possible

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87msjp1pf6.ffs@tglx>
Date: Mon, 30 Sep 2024 11:06:21 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Peter Zijlstra <peterz@...radead.org>, Michael Kelley
 <mhklinux@...look.com>
Cc: Borislav Petkov <bp@...en8.de>, Yury Norov <yury.norov@...il.com>,
 "x86@...nel.org" <x86@...nel.org>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>
Subject: Re: Question about num_possible_cpus() and cpu_possible_mask

On Mon, Sep 30 2024 at 09:56, Peter Zijlstra wrote:
> On Wed, Sep 25, 2024 at 04:04:33AM +0000, Michael Kelley wrote:
>> Question:  Is there any intention to guarantee that the cpu_possible_mask is
>> "dense", in that all bit positions 0 thru (nr_cpu_ids - 1) are set, with no
>> "holes"? If that were true, then num_possible_cpus() would be equal to
>> nr_cpu_ids.
>
> I think we've historically had machines where there were holes in. And I
> think we're wanting to have holes in for modern hybrid x86 that have HT,
> although I'm not entirely sure where those patches are atm.
>
> Thomas, didn't we have a patch that renumbers CPUs for hybrid crud sich
> that HT is always the low bit and we end up with holes because the atoms
> don't have HT on?
>
> Or was that on my plate and it got lost in the giant todo pile?

We talked about it some time ago, but that went nowhere.

Thanks,

        tglx