:orphan:

.. title:: SCHED_CPU_MASK

.. option:: 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
===================

\ :option:`SCHED_DUMB <CONFIG_SCHED_DUMB>`

*(Includes any dependencies from ifs and menus.)*

Defaults
========

No defaults. Implicitly defaults to ``n``.

Kconfig definition
==================

.. highlight:: kconfig

At ``kernel/Kconfig:132``

Included via ``Kconfig:8`` → ``Kconfig.zephyr:30``

Menu path: (Top) → General Kernel Options

.. parsed-literal::

    config SCHED_CPU_MASK
    	bool "Enable CPU mask affinity/pinning API"
    	depends on \ :option:`SCHED_DUMB <CONFIG_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.)*