Lines Matching +full:zephyr +full:- +full:bugs +full:-

6 On multiprocessor architectures, Zephyr supports the use of multiple
7 physical CPUs running Zephyr application code.  This support is
9 default.  Any processor is capable of running any Zephyr thread, with
10 access to all standard Zephyr APIs supported.
13 this feature.  If there are two Zephyr application threads runnable on
26 non-Zephyr code).
31 At the application level, core Zephyr IPC and synchronization
36 At the lowest level, however, Zephyr code has often used the
52 needed to wait for the other CPU to exit the lock.  The default Zephyr
54 on top of the pre-existing :c:struct:`atomic_` layer (itself usually
65 re-acquire it or it will deadlock (it is perfectly legal to nest
67 detect and report bugs like this.
71 recursive semantics above, spinlocks in single-CPU contexts produce
73 Zephyr core kernel has now been ported to use spinlocks exclusively.
85 and that it is re-acquired when necessary to restore the lock state
101 kernel scheduler to decide on which threads to execute.  Zephyr
109 :c:func:`k_thread_cpu_mask_enable` will re-enable execution.  There are also
113 suspended, otherwise an ``-EINVAL`` will be returned.
116 involved in doing the per-CPU mask test requires that the list be
117 traversed in full.  The kernel does not keep a per-CPU run queue.
127 A Zephyr SMP kernel begins boot identically to a uniprocessor kernel.
146 many architectures the timer is a per-CPU device and needs to be
149 guarantee that all SMP initialization is complete before any Zephyr
157    :figclass: align-center
169 One example is the Zephyr :c:func:`k_thread_abort` API, which cannot return
175 that system idle be implemented using a low-power mode with as many
179 handle the newly-runnable load.
181 So where possible, Zephyr SMP architectures should implement an
191 APIs will evolve over time to encompass more functionality (e.g. cross-CPU
192 calls), and that the scheduler-specific calls here will be implemented in
197 Zephyr provides fallback behavior that is correct, but perhaps
204 "DEAD" or for it to re-enter the queue (in which case we terminate it
220 that case is more invasive: Zephyr will **not** enter the system idle
242     may be more than one valid set--one of which may be optimal.
244     To better illustrate the distinction, consider a 2-CPU system with ready
258 There are three types of costs/penalties associated with the IPI cascades--and
270 In general, Zephyr kernel code is SMP-agnostic and, like application
275 Per-CPU data
281 running concurrently.  Likewise a kernel-provided interrupt stack
294 implemented using a CPU-provided register or addressing mode that can
296 make it available to any kernel-mode code.
298 Similarly, where on a uniprocessor system Zephyr could simply create a
306 Switch-based context switching
309 The traditional Zephyr context switch primitive has been :c:func:`z_swap`.
321 with the swap call, and as we don't want per-architecture assembly
322 code to be handling scheduler internal state, Zephyr requires a
323 somewhat lower-level context switch primitives for SMP systems:
333 Similarly, on interrupt exit, switch-based architectures are expected
342 the caller-saved registers on the current thread's stack when interrupted
343 in order to minimize interrupt latency, and preserve the callee-saved