From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CE20218B475 for ; Mon, 25 Nov 2024 08:38:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732523880; cv=none; b=FQkiaQArVjID6/Dx0nfrEldUNN+OpKn9TVaa8w6qSS4v50caQgVkApz+08l8I7vg1BHLmt7spsGMcSdPOobTvy/ZFjY9I5+gmkU/7A7dOuz4s41psqeT256U5YxkWa8n/8N3EzgZ/Rcl4w4wq+QqaHXxdrvjmu+Vvdzle/SdWaA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732523880; c=relaxed/simple; bh=lFy8jCbAa4BewXdTwk2+qDv8pSO5e70DGDXVWy7ZdIM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NWfatEoTkwt3Azu7RcFFTDuECagOkBYsyeGGHAdjhkOcSHiXJUnlMjn2Xtc7FRjGmCezAJeGgn5m1r/zmNTxPiZYZzRzBggWBDJgplnTZwXXXsT1ngFKuGFrXgO30LNIRNqr72OfysohCKNJDa/dxxMG1kjLfWagI6vWw6V7zzY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Vsno5DUB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Vsno5DUB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 818FEC4CECE; Mon, 25 Nov 2024 08:37:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1732523880; bh=lFy8jCbAa4BewXdTwk2+qDv8pSO5e70DGDXVWy7ZdIM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Vsno5DUBYpigSJD6VlxPh87VBwhaCezi9Q0OkTpBfsWuVM9NlW4ZfKnQVoEgWtrWO QXF6Pf104+Lx85jsaoAddG4ffDhme/+Rxa+t31flgoglF4BUfWmhPj1X7YOXJUMKww 0kx7aT2Sc9IptrGqHfbvPJuEvTMpcvJHJHPxqbxYAOg284OFx6RZ+Cvm6XVVzpuuPF 1bczUVjyzKnT3m3q8jLh5iTfHBkfjC7ZKkxw/+RWeV0hwx1fiklJ9rjD2bpo3t6x3u FF5799IQsaYMZqMWVdaCPWt6ApIuRNW9q9RN0lY3KiRs8rK2AZpv3vzkn6TLxMbmWh uu3tGQceAnvTg== Date: Mon, 25 Nov 2024 09:37:56 +0100 From: Ingo Molnar To: Fernando Fernandez Mancera Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de, x86@kernel.org Subject: Re: [PATCH RESEND] x86/cpu/topology: remove limit of CPUs due to noapic on x86_64 Message-ID: References: <20241124174510.2561-1-ffmancera@riseup.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241124174510.2561-1-ffmancera@riseup.net> * Fernando Fernandez Mancera wrote: > On x86_64 the command line parameter "noapic" should not limit the > number of possible CPUs, as it only limits the use of IRQ sharing or > device IRQ remapping. Only on x86_32 the command line parameter > "nolapic" limits the number of possible CPUs to one. This restores the > behavior previous to the rework of possible CPU management. So what's the motivation? Arguably the x86-64 boot option behavior was weird: a working local APIC is very much needed to have an SMP system. If we want to disable IRQ sharing or device IRQ remapping, then that should have an appropriately named boot command line option. Does some system require that perhaps? Thanks, Ingo