CONFIG_SCHED_CPU_MASK

Enable CPU mask affinity/pinning API

Type: bool

Help

When true, the application will have access to the
k_thread_cpu_mask_*() APIs which control per-CPU affinity masks in
SMP mode, allowing applications to pin threads to specific CPUs or
disallow threads from running on given CPUs.  Note that as currently
implemented, this involves an inherent O(N) scaling in the number of
idle-but-runnable threads, and thus works only with the DUMB
scheduler (as SCALABLE and MULTIQ would see no benefit).

Note that this setting does not technically depend on SMP and is
implemented without it for testing purposes, but for obvious reasons
makes sense as an application API only where there is more than one
CPU.  With one CPU, it's just a higher overhead version of
k_thread_start/stop().

Direct dependencies

(SMP && SOC_ESP32) || (SMP && SOC_ESP32) || SCHED_DUMB

(Includes any dependencies from ifs and menus.)

Defaults

• y

• y

Kconfig definitions

At <Zephyr>/soc/xtensa/esp32/Kconfig.defconfig:36

Included via <Zephyr>/Kconfig:8 → <Zephyr>/Kconfig.zephyr:25 → <nRF>/doc/_build/kconfig/Kconfig.soc.defconfig:1

Menu path: (Top)

config SCHED_CPU_MASK
    bool
    default y
    depends on SMP && SOC_ESP32

---

At <Zephyr>/soc/xtensa/esp32/Kconfig.defconfig:36

Included via <Zephyr>/Kconfig:8 → <Zephyr>/Kconfig.zephyr:27

Menu path: (Top)

config SCHED_CPU_MASK
    bool
    default y
    depends on SMP && SOC_ESP32

---

At <Zephyr>/kernel/Kconfig:121

Included via <Zephyr>/Kconfig:8 → <Zephyr>/Kconfig.zephyr:40

Menu path: (Top) → General Kernel Options

config SCHED_CPU_MASK
    bool "Enable CPU mask affinity/pinning API"
    depends on SCHED_DUMB
    help
      When true, the application will have access to the
      k_thread_cpu_mask_*() APIs which control per-CPU affinity masks in
      SMP mode, allowing applications to pin threads to specific CPUs or
      disallow threads from running on given CPUs.  Note that as currently
      implemented, this involves an inherent O(N) scaling in the number of
      idle-but-runnable threads, and thus works only with the DUMB
      scheduler (as SCALABLE and MULTIQ would see no benefit).

      Note that this setting does not technically depend on SMP and is
      implemented without it for testing purposes, but for obvious reasons
      makes sense as an application API only where there is more than one
      CPU.  With one CPU, it's just a higher overhead version of
      k_thread_start/stop().

(The ‘depends on’ condition includes propagated dependencies from ifs and menus.)