:orphan:

.. title:: CONFIG_SCHED_MULTIQ

.. kconfig:: CONFIG_SCHED_MULTIQ

CONFIG_SCHED_MULTIQ
###################

*Traditional multi-queue ready queue*

Type: ``bool``

Help
====

.. code-block:: none

    When selected, the scheduler ready queue will be implemented
    as the classic/textbook array of lists, one per priority
    (max 32 priorities).  This corresponds to the scheduler
    algorithm used in Zephyr versions prior to 1.12.  It incurs
    only a tiny code size overhead vs. the "dumb" scheduler and
    runs in O(1) time in almost all circumstances with very low
    constant factor.  But it requires a fairly large RAM budget
    to store those list heads, and the limited features make it
    incompatible with features like deadline scheduling that
    need to sort threads more finely, and SMP affinity which
    need to traverse the list of threads.  Typical applications
    with small numbers of runnable threads probably want the
    DUMB scheduler.

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

!\ :kconfig:`SCHED_DEADLINE <CONFIG_SCHED_DEADLINE>` && \ :ref:`<choice SCHED_ALGORITHM: Scheduler priority queue algorithm> <choice_276>`

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

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



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

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

Menu path: (Top) → General Kernel Options → Scheduler priority queue algorithm

.. code-block:: kconfig

    config SCHED_MULTIQ
    	bool "Traditional multi-queue ready queue"
    	depends on !SCHED_DEADLINE && <choice SCHED_ALGORITHM>
    	help
    	  When selected, the scheduler ready queue will be implemented
    	  as the classic/textbook array of lists, one per priority
    	  (max 32 priorities).  This corresponds to the scheduler
    	  algorithm used in Zephyr versions prior to 1.12.  It incurs
    	  only a tiny code size overhead vs. the "dumb" scheduler and
    	  runs in O(1) time in almost all circumstances with very low
    	  constant factor.  But it requires a fairly large RAM budget
    	  to store those list heads, and the limited features make it
    	  incompatible with features like deadline scheduling that
    	  need to sort threads more finely, and SMP affinity which
    	  need to traverse the list of threads.  Typical applications
    	  with small numbers of runnable threads probably want the
    	  DUMB scheduler.

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