Lines Matching full:cpus
7 physical CPUs running Zephyr application code. This support is
20 number of physical CPUs available is visible at build time as
22 number of available CPUs on the platform and it is not expected that
62 subsystems or data structures, preventing CPUs from contending on a
83 threads. The kernel will ensure that only one thread across all CPUs
86 when a thread is switched in. Other CPUs will spin waiting for the
100 partition work across physical CPUs instead of relying solely on the
103 kconfig variable, which can associate a specific set of CPUs with each
104 thread, indicating on which CPUs it can run.
128 Auxiliary CPUs begin in a disabled state in the architecture layer.
130 happens on a single CPU before other CPUs are brought online.
134 enumerates over the configured CPUs, calling into the architecture
147 configured specially on auxiliary CPUs. Then it waits (spinning) for
160 two CPUs and two app threads which begin operating simultaneously.
184 which when invoked will flag an interrupt on all CPUs (except the current one,
188 when invoked will flag an interrupt on the specified CPUs. When an interrupt is
189 flagged on the CPUs, the :c:func:`z_sched_ipi` function implemented in the
190 scheduler will get invoked on those CPUs. The expectation is that these
214 have been idle CPUs), we broadcast an IPI. A foreign CPU will then be
231 The kernel can not control the order in which IPIs are processed by the CPUs
233 sufficient to trigger a reschedule on the N CPUs that results with them
236 with an optimal set of threads) that can be scheduled on the N CPUs and a
256 ready threads for the CPUs.
262 other CPUs. The second is a cost incurred by the CPUs receiving the IPIs as
271 code, will work correctly regardless of the number of CPUs available.
286 within the :c:struct:`_kernel` struct, which has a ``cpus[]`` array indexed by ID.
288 to access the fields of ``cpus[0]`` using the older syntax and assembly