:orphan:

.. title:: CONFIG_SCHED_CPU_MASK

.. kconfig:: CONFIG_SCHED_CPU_MASK

CONFIG_SCHED_CPU_MASK
#####################

*Enable CPU mask affinity/pinning API*

Type: ``bool``

Help
====

.. code-block:: none

    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
===================

\ :kconfig:`SCHED_DUMB <CONFIG_SCHED_DUMB>`

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

Defaults
========

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

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



At ``<Zephyr Kernel>/Kconfig:121``

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

Menu path: (Top) → General Kernel Options

.. code-block:: kconfig

    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.)*