Forum | Documentation | Website | Blog

Skip to content
Snippets Groups Projects
  1. Aug 07, 2023
    • Tejun Heo's avatar
      workqueue: Add multiple affinity scopes and interface to select them · 63c5484e
      Tejun Heo authored
      
      Add three more affinity scopes - WQ_AFFN_CPU, SMT and CACHE - and make CACHE
      the default. The code changes to actually add the additional scopes are
      trivial.
      
      Also add module parameter "workqueue.default_affinity_scope" to override the
      default scope and "affinity_scope" sysfs file to configure it per workqueue.
      wq_dump.py and documentations are updated accordingly.
      
      This enables significant flexibility in configuring how unbound workqueues
      behave. If affinity scope is set to "cpu", it'll behave close to a per-cpu
      workqueue. On the other hand, "system" removes all locality boundaries.
      
      Many modern machines have multiple L3 caches often while being mostly
      uniform in terms of memory access. Thus, workqueue's previous behavior of
      spreading work items in each NUMA node had negative performance implications
      from unncessarily crossing L3 boundaries between issue and execution.
      However, picking a finer grained affinity scope also has a downside in that
      an issuer in one group can't utilize CPUs in other groups.
      
      While dependent on the specifics of workload, there's usually a noticeable
      penalty in crossing L3 boundaries, so let's default to CACHE. This issue
      will be further addressed and documented with examples in future patches.
      
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      63c5484e
    • Tejun Heo's avatar
      workqueue: Add tools/workqueue/wq_dump.py which prints out workqueue configuration · 7f7dc377
      Tejun Heo authored
      
      Lack of visibility has always been a pain point for workqueues. While the
      recently added wq_monitor.py improved the situation, it's still difficult to
      understand what worker pools are active in the system, how workqueues map to
      them and why. The lack of visibility into how workqueues are configured is
      going to become more noticeable as workqueue improves locality awareness and
      provides more mechanisms to customize locality related behaviors.
      
      Now that the basic framework for more flexible locality support is in place,
      this is a good time to improve the situation. This patch adds
      tools/workqueues/wq_dump.py which prints out the topology configuration,
      worker pools and how workqueues are mapped to pools. Read the command's help
      message for more details.
      
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      7f7dc377