Skip to content
  • Thomas Gleixner's avatar
    Revert "lib: Restrict cpumask_local_spread to houskeeping CPUs" · 2452483d
    Thomas Gleixner authored
    This reverts commit 1abdfe70
    
    .
    
    This change is broken and not solving any problem it claims to solve.
    
    Robin reported that cpumask_local_spread() now returns any cpu out of
    cpu_possible_mask in case that NOHZ_FULL is disabled (runtime or compile
    time). It can also return any offline or not-present CPU in the
    housekeeping mask. Before that it was returning a CPU out of
    online_cpu_mask.
    
    While the function is racy against CPU hotplug if the caller does not
    protect against it, the actual use cases are not caring much about it as
    they use it mostly as hint for:
    
     - the user space affinity hint which is unused by the kernel
     - memory node selection which is just suboptimal
     - network queue affinity which might fail but is handled gracefully
    
    But the occasional fail vs. hotplug is very different from returning
    anything from possible_cpu_mask which can have a large amount of offline
    CPUs obviously.
    
    The changelog of the commit claims:
    
     "The current implementation of cpumask_local_spread() does not respect
      the isolated CPUs, i.e., even if a CPU has been isolated for Real-Time
      task, it will return it to the caller for pinning of its IRQ
      threads. Having these unwanted IRQ threads on an isolated CPU adds up
      to a latency overhead."
    
    The only correct part of this changelog is:
    
     "The current implementation of cpumask_local_spread() does not respect
      the isolated CPUs."
    
    Everything else is just disjunct from reality.
    
    Reported-by: default avatarRobin Murphy <robin.murphy@arm.com>
    Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Cc: Nitesh Narayan Lal <nitesh@redhat.com>
    Cc: Marcelo Tosatti <mtosatti@redhat.com>
    Cc: abelits@marvell.com
    Cc: davem@davemloft.net
    Link: https://lore.kernel.org/r/87y2g26tnt.fsf@nanos.tec.linutronix.de
    2452483d