--- /dev/null
+<!-- Copyright (C) 2003 Red Hat, Inc. -->
+<!-- This material may be distributed only subject to the terms -->
+<!-- and conditions set forth in the Open Publication License, v1.0 -->
+<!-- or later (the latest version is presently available at -->
+<!-- http://www.opencontent.org/openpub/). -->
+<!-- Distribution of the work or derivative of the work in any -->
+<!-- standard (paper) book form is prohibited unless prior -->
+<!-- permission is obtained from the copyright holder. -->
+<HTML
+><HEAD
+><TITLE
+>SMP Support</TITLE
+><meta name="MSSmartTagsPreventParsing" content="TRUE">
+<META
+NAME="GENERATOR"
+CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
+"><LINK
+REL="HOME"
+TITLE="eCos Reference Manual"
+HREF="ecos-ref.html"><LINK
+REL="UP"
+TITLE="The eCos Kernel"
+HREF="kernel.html"><LINK
+REL="PREVIOUS"
+TITLE="Kernel Overview"
+HREF="kernel-overview.html"><LINK
+REL="NEXT"
+TITLE="Thread creation"
+HREF="kernel-thread-create.html"></HEAD
+><BODY
+CLASS="REFENTRY"
+BGCOLOR="#FFFFFF"
+TEXT="#000000"
+LINK="#0000FF"
+VLINK="#840084"
+ALINK="#0000FF"
+><DIV
+CLASS="NAVHEADER"
+><TABLE
+SUMMARY="Header navigation table"
+WIDTH="100%"
+BORDER="0"
+CELLPADDING="0"
+CELLSPACING="0"
+><TR
+><TH
+COLSPAN="3"
+ALIGN="center"
+>eCos Reference Manual</TH
+></TR
+><TR
+><TD
+WIDTH="10%"
+ALIGN="left"
+VALIGN="bottom"
+><A
+HREF="kernel-overview.html"
+ACCESSKEY="P"
+>Prev</A
+></TD
+><TD
+WIDTH="80%"
+ALIGN="center"
+VALIGN="bottom"
+></TD
+><TD
+WIDTH="10%"
+ALIGN="right"
+VALIGN="bottom"
+><A
+HREF="kernel-thread-create.html"
+ACCESSKEY="N"
+>Next</A
+></TD
+></TR
+></TABLE
+><HR
+ALIGN="LEFT"
+WIDTH="100%"></DIV
+><H1
+><A
+NAME="KERNEL-SMP">SMP Support</H1
+><DIV
+CLASS="REFNAMEDIV"
+><A
+NAME="AEN206"
+></A
+><H2
+>Name</H2
+>SMP -- Support Symmetric Multiprocessing Systems</DIV
+><DIV
+CLASS="REFSECT1"
+><A
+NAME="KERNEL-SMP-DESCRIPTION"
+></A
+><H2
+>Description</H2
+><P
+>eCos contains support for limited Symmetric Multi-Processing (SMP).
+This is only available on selected architectures and platforms.
+The implementation has a number of restrictions on the kind of
+hardware supported. These are described in <A
+HREF="hal-smp-support.html"
+>the Section called <I
+>SMP Support</I
+> in Chapter 9</A
+>.
+ </P
+><P
+>The following sections describe the changes that have been made to the
+eCos kernel to support SMP operation.
+ </P
+></DIV
+><DIV
+CLASS="REFSECT1"
+><A
+NAME="KERNEL-SMP-STARTUP"
+></A
+><H2
+>System Startup</H2
+><P
+>The system startup sequence needs to be somewhat different on an SMP
+system, although this is largely transparent to application code. The
+main startup takes place on only one CPU, called the primary CPU. All
+other CPUs, the secondary CPUs, are either placed in suspended state
+at reset, or are captured by the HAL and put into a spin as they start
+up. The primary CPU is responsible for copying the DATA segment and
+zeroing the BSS (if required), calling HAL variant and platform
+initialization routines and invoking constructors. It then calls
+<TT
+CLASS="FUNCTION"
+>cyg_start</TT
+> to enter the application. The
+application may then create extra threads and other objects.
+ </P
+><P
+>It is only when the application calls
+<TT
+CLASS="FUNCTION"
+>cyg_scheduler_start</TT
+> that the secondary CPUs are
+initialized. This routine scans the list of available secondary CPUs
+and invokes <TT
+CLASS="FUNCTION"
+>HAL_SMP_CPU_START</TT
+> to start each
+CPU. Finally it calls an internal function
+<TT
+CLASS="FUNCTION"
+>Cyg_Scheduler::start_cpu</TT
+> to enter the scheduler
+for the primary CPU.
+ </P
+><P
+>Each secondary CPU starts in the HAL, where it completes any per-CPU
+initialization before calling into the kernel at
+<TT
+CLASS="FUNCTION"
+>cyg_kernel_cpu_startup</TT
+>. Here it claims the
+scheduler lock and calls
+<TT
+CLASS="FUNCTION"
+>Cyg_Scheduler::start_cpu</TT
+>.
+ </P
+><P
+><TT
+CLASS="FUNCTION"
+>Cyg_Scheduler::start_cpu</TT
+> is common to both the
+primary and secondary CPUs. The first thing this code does is to
+install an interrupt object for this CPU's inter-CPU interrupt. From
+this point on the code is the same as for the single CPU case: an
+initial thread is chosen and entered.
+ </P
+><P
+>From this point on the CPUs are all equal, eCos makes no further
+distinction between the primary and secondary CPUs. However, the
+hardware may still distinguish between them as far as interrupt
+delivery is concerned.
+ </P
+></DIV
+><DIV
+CLASS="REFSECT1"
+><A
+NAME="KERNEL-SMP-SCHEDULING"
+></A
+><H2
+>Scheduling</H2
+><P
+>To function correctly an operating system kernel must protect its
+vital data structures, such as the run queues, from concurrent
+access. In a single CPU system the only concurrent activities to worry
+about are asynchronous interrupts. The kernel can easily guard its
+data structures against these by disabling interrupts. However, in a
+multi-CPU system, this is inadequate since it does not block access by
+other CPUs.
+ </P
+><P
+>The eCos kernel protects its vital data structures using the scheduler
+lock. In single CPU systems this is a simple counter that is
+atomically incremented to acquire the lock and decremented to release
+it. If the lock is decremented to zero then the scheduler may be
+invoked to choose a different thread to run. Because interrupts may
+continue to be serviced while the scheduler lock is claimed, ISRs are
+not allowed to access kernel data structures, or call kernel routines
+that can. Instead all such operations are deferred to an associated
+DSR routine that is run during the lock release operation, when the
+data structures are in a consistent state.
+ </P
+><P
+>By choosing a kernel locking mechanism that does not rely on interrupt
+manipulation to protect data structures, it is easier to convert eCos
+to SMP than would otherwise be the case. The principal change needed to
+make eCos SMP-safe is to convert the scheduler lock into a nestable
+spin lock. This is done by adding a spinlock and a CPU id to the
+original counter.
+ </P
+><P
+>The algorithm for acquiring the scheduler lock is very simple. If the
+scheduler lock's CPU id matches the current CPU then it can just increment
+the counter and continue. If it does not match, the CPU must spin on
+the spinlock, after which it may increment the counter and store its
+own identity in the CPU id.
+ </P
+><P
+>To release the lock, the counter is decremented. If it goes to zero
+the CPU id value must be set to NONE and the spinlock cleared.
+ </P
+><P
+>To protect these sequences against interrupts, they must be performed
+with interrupts disabled. However, since these are very short code
+sequences, they will not have an adverse effect on the interrupt
+latency.
+ </P
+><P
+>Beyond converting the scheduler lock, further preparing the kernel for
+SMP is a relatively minor matter. The main changes are to convert
+various scalar housekeeping variables into arrays indexed by CPU
+id. These include the current thread pointer, the need_reschedule
+flag and the timeslice counter.
+ </P
+><P
+>At present only the Multi-Level Queue (MLQ) scheduler is capable of
+supporting SMP configurations. The main change made to this scheduler
+is to cope with having several threads in execution at the same
+time. Running threads are marked with the CPU that they are executing on.
+When scheduling a thread, the scheduler skips past any running threads
+until it finds a thread that is pending. While not a constant-time
+algorithm, as in the single CPU case, this is still deterministic,
+since the worst case time is bounded by the number of CPUs in the
+system.
+ </P
+><P
+>A second change to the scheduler is in the code used to decide when
+the scheduler should be called to choose a new thread. The scheduler
+attempts to keep the <SPAN
+CLASS="PROPERTY"
+>n</SPAN
+> CPUs running the
+<SPAN
+CLASS="PROPERTY"
+>n</SPAN
+> highest priority threads. Since an event or
+interrupt on one CPU may require a reschedule on another CPU, there
+must be a mechanism for deciding this. The algorithm currently
+implemented is very simple. Given a thread that has just been awakened
+(or had its priority changed), the scheduler scans the CPUs, starting
+with the one it is currently running on, for a current thread that is
+of lower priority than the new one. If one is found then a reschedule
+interrupt is sent to that CPU and the scan continues, but now using
+the current thread of the rescheduled CPU as the candidate thread. In
+this way the new thread gets to run as quickly as possible, hopefully
+on the current CPU, and the remaining CPUs will pick up the remaining
+highest priority threads as a consequence of processing the reschedule
+interrupt.
+ </P
+><P
+>The final change to the scheduler is in the handling of
+timeslicing. Only one CPU receives timer interrupts, although all CPUs
+must handle timeslicing. To make this work, the CPU that receives the
+timer interrupt decrements the timeslice counter for all CPUs, not
+just its own. If the counter for a CPU reaches zero, then it sends a
+timeslice interrupt to that CPU. On receiving the interrupt the
+destination CPU enters the scheduler and looks for another thread at
+the same priority to run. This is somewhat more efficient than
+distributing clock ticks to all CPUs, since the interrupt is only
+needed when a timeslice occurs.
+ </P
+><P
+>All existing synchronization mechanisms work as before in an SMP
+system. Additional synchronization mechanisms have been added to
+provide explicit synchronization for SMP, in the form of
+<A
+HREF="kernel-spinlocks.html"
+>spinlocks</A
+>.
+ </P
+></DIV
+><DIV
+CLASS="REFSECT1"
+><A
+NAME="KERNEL-SMP-INTERRUPTS"
+></A
+><H2
+>SMP Interrupt Handling</H2
+><P
+>The main area where the SMP nature of a system requires special
+attention is in device drivers and especially interrupt handling. It
+is quite possible for the ISR, DSR and thread components of a device
+driver to execute on different CPUs. For this reason it is much more
+important that SMP-capable device drivers use the interrupt-related
+functions correctly. Typically a device driver would use the driver
+API rather than call the kernel directly, but it is unlikely that
+anybody would attempt to use a multiprocessor system without the
+kernel package.
+ </P
+><P
+>Two new functions have been added to the Kernel API
+to do <A
+HREF="kernel-interrupts.html#KERNEL-INTERRUPTS-SMP"
+>interrupt
+routing</A
+>: <TT
+CLASS="FUNCTION"
+>cyg_interrupt_set_cpu</TT
+> and
+<TT
+CLASS="FUNCTION"
+>cyg_interrupt_get_cpu</TT
+>. Although not currently
+supported, special values for the cpu argument may be used in future
+to indicate that the interrupt is being routed dynamically or is
+CPU-local. Once a vector has been routed to a new CPU, all other
+interrupt masking and configuration operations are relative to that
+CPU, where relevant.
+ </P
+><P
+>There are more details of how interrupts should be handled in SMP
+systems in <A
+HREF="devapi-smp-support.html"
+>the Section called <I
+>SMP Support</I
+> in Chapter 18</A
+>.
+ </P
+></DIV
+><DIV
+CLASS="NAVFOOTER"
+><HR
+ALIGN="LEFT"
+WIDTH="100%"><TABLE
+SUMMARY="Footer navigation table"
+WIDTH="100%"
+BORDER="0"
+CELLPADDING="0"
+CELLSPACING="0"
+><TR
+><TD
+WIDTH="33%"
+ALIGN="left"
+VALIGN="top"
+><A
+HREF="kernel-overview.html"
+ACCESSKEY="P"
+>Prev</A
+></TD
+><TD
+WIDTH="34%"
+ALIGN="center"
+VALIGN="top"
+><A
+HREF="ecos-ref.html"
+ACCESSKEY="H"
+>Home</A
+></TD
+><TD
+WIDTH="33%"
+ALIGN="right"
+VALIGN="top"
+><A
+HREF="kernel-thread-create.html"
+ACCESSKEY="N"
+>Next</A
+></TD
+></TR
+><TR
+><TD
+WIDTH="33%"
+ALIGN="left"
+VALIGN="top"
+>Kernel Overview</TD
+><TD
+WIDTH="34%"
+ALIGN="center"
+VALIGN="top"
+><A
+HREF="kernel.html"
+ACCESSKEY="U"
+>Up</A
+></TD
+><TD
+WIDTH="33%"
+ALIGN="right"
+VALIGN="top"
+>Thread creation</TD
+></TR
+></TABLE
+></DIV
+></BODY
+></HTML
+>
\ No newline at end of file
projects / karo-tx-redboot.git / blobdiff