Lines Matching full:that
8 "symmetric" in the sense that no specific CPU is treated specially by
22 number of available CPUs on the platform and it is not expected that
40 does not: the fact that your CPU will not be interrupted while you are
49 that not only masks interrupts locally, as done by :c:func:`irq_lock`, but
50 also atomically validates that a shared lock variable has been
58 One important difference between IRQ locks and spinlocks is that the
63 single global resource. But that means that spinlocks must not be
64 used recursively. Code that holds a specific lock must not try to
83 threads. The kernel will ensure that only one thread across all CPUs
84 can hold the lock at any time, that it is released on context switch,
85 and that it is re-acquired when necessary to restore the lock state
92 instruction) interrupt masking operation. That, and the fact that the
93 IRQ lock is global, means that code expecting to be run in an SMP
108 that thread from running on that CPU in the future. Likewise
115 Note that when this feature is enabled, the scheduler algorithm
116 involved in doing the per-CPU mask test requires that the list be
118 That means that the performance benefits from the
137 practice it uses the area that will become that CPU's interrupt
139 run on that CPU, and a pointer to a "start flag" address which will be
143 invoked by the architecture layer. Note that interrupts are still
149 guarantee that all SMP initialization is complete before any Zephyr
166 case that state modified on the local CPU needs to be synchronously
170 until the thread that had been aborted is no longer runnable. If it
171 is currently running on another CPU, that becomes difficult to
175 that system idle be implemented using a low-power mode with as many
185 though that is allowed behavior). If the architecture supports directed IPIs
190 scheduler will get invoked on those CPUs. The expectation is that these
192 calls), and that the scheduler-specific calls here will be implemented in
195 Note that not all SMP architectures will have a usable IPI mechanism
197 Zephyr provides fallback behavior that is correct, but perhaps
205 the same way we would have in uniprocessor mode). Note that the
218 Without an IPI, however, a low power idle that requires an interrupt
220 that case is more invasive: Zephyr will **not** enter the system idle
222 state at high frequency (not spinning on it though, as that would
224 that power constrained SMP applications are always going to provide an
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
291 Note that an important requirement on the architecture layer is that
293 context. The expectation is that :c:func:`arch_curr_cpu` will be
294 implemented using a CPU-provided register or addressing mode that can
311 switch to. The expectation has always been that the scheduler has
315 offset. That technique will not work in SMP, because the other CPU
317 the scheduler (for example: it might already be running that cached
328 resulting from the thread that is being switched out.
337 used by :c:func:`arch_switch`, or NULL if that thread cannot be released
349 In the former case it is up to that switch code to store the handle
350 resulting from the thread that is being switched out in that thread's
354 thread state may pass that thread's handle directly to
357 Note that while SMP requires :kconfig:option:`CONFIG_USE_SWITCH`, the reverse is not