:orphan:

.. title:: CONFIG_SCHED_CPU_MASK_PIN_ONLY

.. kconfig:: CONFIG_SCHED_CPU_MASK_PIN_ONLY

CONFIG_SCHED_CPU_MASK_PIN_ONLY
##############################

*CPU mask variant with single-CPU pinning only*

Type: ``bool``

Help
====

.. code-block:: none

    When true, enables a variant of SCHED_CPU_MASK where only
    one CPU may be specified for every thread.  Effectively, all
    threads have a single "assigned" CPU and they will never be
    scheduled symmetrically.  In general this is not helpful,
    but some applications have a carefully designed threading
    architecture and want to make their own decisions about how
    to assign work to CPUs.  In that circumstance, some moderate
    optimizations can be made (e.g. having a separate run queue
    per CPU, keeping the list length shorter).  Most
    applications don't want this.

Direct dependencies
===================

\ :kconfig:`SMP <CONFIG_SMP>` && \ :kconfig:`SCHED_CPU_MASK <CONFIG_SCHED_CPU_MASK>`

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

Defaults
========

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

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



At ``<Kernel>/Kconfig:139``

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

Menu path: (Top) → General Kernel Options → Enable CPU mask affinity/pinning API

.. code-block:: kconfig

    config SCHED_CPU_MASK_PIN_ONLY
    	bool "CPU mask variant with single-CPU pinning only"
    	depends on SMP && SCHED_CPU_MASK
    	help
    	  When true, enables a variant of SCHED_CPU_MASK where only
    	  one CPU may be specified for every thread.  Effectively, all
    	  threads have a single "assigned" CPU and they will never be
    	  scheduled symmetrically.  In general this is not helpful,
    	  but some applications have a carefully designed threading
    	  architecture and want to make their own decisions about how
    	  to assign work to CPUs.  In that circumstance, some moderate
    	  optimizations can be made (e.g. having a separate run queue
    	  per CPU, keeping the list length shorter).  Most
    	  applications don't want this.

*(The 'depends on' condition includes propagated dependencies from ifs and menus.)*