108 lines
3.6 KiB
Plaintext
108 lines
3.6 KiB
Plaintext
|
# Copyright (c) 2024 Intel Corp.
|
||
|
# SPDX-License-Identifier: Apache-2.0
|
||
|
#
|
||
|
menu "SMP Options"
|
||
|
|
||
|
config SMP
|
||
|
bool "Symmetric multiprocessing support"
|
||
|
depends on USE_SWITCH
|
||
|
depends on !ATOMIC_OPERATIONS_C
|
||
|
help
|
||
|
When true, kernel will be built with SMP support, allowing
|
||
|
more than one CPU to schedule Zephyr tasks at a time.
|
||
|
|
||
|
config USE_SWITCH
|
||
|
bool "Use new-style _arch_switch instead of arch_swap"
|
||
|
depends on USE_SWITCH_SUPPORTED
|
||
|
help
|
||
|
The _arch_switch() API is a lower level context switching
|
||
|
primitive than the original arch_swap mechanism. It is required
|
||
|
for an SMP-aware scheduler, or if the architecture does not
|
||
|
provide arch_swap. In uniprocess situations where the
|
||
|
architecture provides both, _arch_switch incurs more somewhat
|
||
|
overhead and may be slower.
|
||
|
|
||
|
config USE_SWITCH_SUPPORTED
|
||
|
bool
|
||
|
help
|
||
|
Indicates whether _arch_switch() API is supported by the
|
||
|
currently enabled platform. This option should be selected by
|
||
|
platforms that implement it.
|
||
|
|
||
|
config SMP_BOOT_DELAY
|
||
|
bool "Delay booting secondary cores"
|
||
|
depends on SMP
|
||
|
help
|
||
|
By default Zephyr will boot all available CPUs during start up.
|
||
|
Select this option to skip this and allow custom code
|
||
|
(architecture/SoC/board/application) to boot secondary CPUs at
|
||
|
a later time.
|
||
|
|
||
|
config MP_NUM_CPUS
|
||
|
int "Number of CPUs/cores [DEPRECATED]"
|
||
|
default MP_MAX_NUM_CPUS
|
||
|
range 1 12
|
||
|
help
|
||
|
This is deprecated, please use MP_MAX_NUM_CPUS instead.
|
||
|
|
||
|
config MP_MAX_NUM_CPUS
|
||
|
int "Maximum number of CPUs/cores"
|
||
|
default 1
|
||
|
range 1 12
|
||
|
help
|
||
|
Maximum number of multiprocessing-capable cores available to the
|
||
|
multicpu API and SMP features.
|
||
|
|
||
|
config SCHED_IPI_SUPPORTED
|
||
|
bool
|
||
|
help
|
||
|
True if the architecture supports a call to
|
||
|
arch_sched_ipi() to broadcast an interrupt that will call
|
||
|
z_sched_ipi() on other CPUs in the system. Required for
|
||
|
k_thread_abort() to operate with reasonable latency
|
||
|
(otherwise we might have to wait for the other thread to
|
||
|
take an interrupt, which can be arbitrarily far in the
|
||
|
future).
|
||
|
|
||
|
config TRACE_SCHED_IPI
|
||
|
bool "Test IPI"
|
||
|
help
|
||
|
When true, it will add a hook into z_sched_ipi(), in order
|
||
|
to check if schedule IPI has called or not, for testing
|
||
|
purpose.
|
||
|
depends on SCHED_IPI_SUPPORTED
|
||
|
depends on MP_MAX_NUM_CPUS>1
|
||
|
|
||
|
config KERNEL_COHERENCE
|
||
|
bool "Place all shared data into coherent memory"
|
||
|
depends on ARCH_HAS_COHERENCE
|
||
|
default y if SMP && MP_MAX_NUM_CPUS > 1
|
||
|
select THREAD_STACK_INFO
|
||
|
help
|
||
|
When available and selected, the kernel will build in a mode
|
||
|
where all shared data is placed in multiprocessor-coherent
|
||
|
(generally "uncached") memory. Thread stacks will remain
|
||
|
cached, as will application memory declared with
|
||
|
__incoherent. This is intended for Zephyr SMP kernels
|
||
|
running on cache-incoherent architectures only. Note that
|
||
|
when this is selected, there is an implicit API change that
|
||
|
assumes cache coherence to any memory passed to the kernel.
|
||
|
Code that creates kernel data structures in uncached regions
|
||
|
may fail strangely. Some assertions exist to catch these
|
||
|
mistakes, but not all circumstances can be tested.
|
||
|
|
||
|
config TICKET_SPINLOCKS
|
||
|
bool "Ticket spinlocks for lock acquisition fairness [EXPERIMENTAL]"
|
||
|
select EXPERIMENTAL
|
||
|
help
|
||
|
Basic spinlock implementation is based on single
|
||
|
atomic variable and doesn't guarantee locking fairness
|
||
|
across multiple CPUs. It's even possible that single CPU
|
||
|
will win the contention every time which will result
|
||
|
in a live-lock.
|
||
|
Ticket spinlocks provide a FIFO order of lock acquisition
|
||
|
which resolves such unfairness issue at the cost of slightly
|
||
|
increased memory footprint.
|
||
|
|
||
|
endmenu
|