[PATCH v12 02/13] lib/group_cpus: remove dead !SMP code

[Aaron Tomlin]

On Mon, Apr 27, 2026 at 05:21:04PM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-04-22 14:52:04 [-0400], Aaron Tomlin wrote:
> > From: Daniel Wagner <wagi at kernel.org>
> > 
> > The support for the !SMP configuration has been removed from the core by
> > commit cac5cefbade9 ("sched/smp: Make SMP unconditional").
> > 
> > While one can technically still compile a uniprocessor kernel, the core
> > scheduler now mandates SMP unconditionally, rendering this particular
> > !SMP fallback handling redundant. Therefore, remove the #ifdef CONFIG_SMP
> > guards and the fallback logic.
> > 
> > Signed-off-by: Daniel Wagner <wagi at kernel.org>
> > Reviewed-by: Martin K. Petersen <martin.petersen at oracle.com>
> > Reviewed-by: Hannes Reinecke <hare at suse.de>
> > [atomlin: Updated commit message to clarify !SMP removal context]
> 
> This look unchanged vs previous submission. You could explain why you
> want to remove the !SMP case. It looks like the !SMP makes things
> easier ;) I don't know how much of this gets removed because of !SMP
> code elsewhere.
> 
> The description still does not make sense/ is accurate.

Hi Sebastian,

Yes, the !SMP path does make things "easier" and lighter for actual UP
builds by bypassing the SMP overhead. However, maintaining two separate
code paths and #ifdef guards for this specific logic adds testing and
maintenance burden that we'd prefer to drop.

The reference to the scheduler commit was meant to highlight a
philosophical alignment-trading a slight performance edge on UP builds in
exchange for a single, unified code path without #ifdef clutter.

How about the following:

    The core scheduler recently transitioned to compiling SMP data structures
    unconditionally to reduce code complexity (see commit cac5cefbade9
    "sched/smp: Make SMP unconditional").

    In alignment with this philosophy of reducing dual-path maintenance, this
    patch removes the #ifdef CONFIG_SMP guards and the dedicated !SMP fallback
    logic here.

    While the !SMP path provided a slightly simpler execution flow for
    uniprocessor kernels (avoiding SMP-specific overhead), maintaining these
    separate code paths adds unnecessary complexity and testing burden.
    Removing these guards simplifies the codebase by standardizing entirely on
    the SMP logic, which safely resolves to single-CPU operations on UP
    configurations.


Kind regards,
-- 
Aaron Tomlin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20260429/47b008a9/attachment-0001.sig>