[HPEMC RHEL 10.1 bug] RHEL 10.1 not booting on systems with more than 4096 cpus (!1670) · Merge requests · Red Hat / centos-stream / src / kernel / centos-stream-10

JIRA: https://issues.redhat.com/browse/RHEL-118742

commit 14c1da3895a116f4e32c20487046655f26d3999b
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Oct 8 13:43:26 2025 -1000

    sched_ext: Allocate scx_kick_cpus_pnt_seqs lazily using kvzalloc()
    
    On systems with >4096 CPUs, scx_kick_cpus_pnt_seqs allocation fails during
    boot because it exceeds the 32,768 byte percpu allocator limit.
    
    Restructure to use DEFINE_PER_CPU() for the per-CPU pointers, with each CPU
    pointing to its own kvzalloc'd array. Move allocation from boot time to
    scx_enable() and free in scx_disable(), so the O(nr_cpu_ids^2) memory is only
    consumed when sched_ext is active.
    
    Use RCU to guard against racing with free. Arrays are freed via call_rcu()
    and kick_cpus_irq_workfn() uses rcu_dereference_bh() with a NULL check.
    
    While at it, rename to scx_kick_pseqs for brevity and update comments to
    clarify these are pick_task sequence numbers.
    
    v2: RCU protect scx_kick_seqs to manage kick_cpus_irq_workfn() racing
        against disable as per Andrea.
    
    v3: Fix bugs notcied by Andrea.
    
    Reported-by: Phil Auld <pauld@redhat.com>
    Link: http://lkml.kernel.org/r/20251007133523.GA93086@pauld.westford.csb
    Cc: Andrea Righi <arighi@nvidia.com>
    Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
    Reviewed-by: Phil Auld <pauld@redhat.com>
    Reviewed-by: Andrea Righi <arighi@nvidia.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>

Signed-off-by: CKI Backport Bot cki-ci-bot+cki-gitlab-backport-bot@redhat.com

Created 2025-10-28 13:30 UTC by backporter - KWF FAQ - Slack #team-kernel-workflow - Source - Documentation - Report an issue

[HPEMC RHEL 10.1 bug] RHEL 10.1 not booting on systems with more than 4096 cpus

Merge request reports