⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 kernel-smp.html

📁 有关ecos2。0介绍了实时嵌入式的结构以及线程调度的实现和内存的管理等
💻 HTML
字号:
<!-- 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"><METANAME="GENERATOR"CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+"><LINKREL="HOME"TITLE="eCos Reference Manual"HREF="ecos-ref.html"><LINKREL="UP"TITLE="The eCos Kernel"HREF="kernel.html"><LINKREL="PREVIOUS"TITLE="Kernel Overview"HREF="kernel-overview.html"><LINKREL="NEXT"TITLE="Thread creation"HREF="kernel-thread-create.html"></HEAD><BODYCLASS="REFENTRY"BGCOLOR="#FFFFFF"TEXT="#000000"LINK="#0000FF"VLINK="#840084"ALINK="#0000FF"><DIVCLASS="NAVHEADER"><TABLESUMMARY="Header navigation table"WIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><THCOLSPAN="3"ALIGN="center">eCos Reference Manual</TH></TR><TR><TDWIDTH="10%"ALIGN="left"VALIGN="bottom"><AHREF="kernel-overview.html"ACCESSKEY="P">Prev</A></TD><TDWIDTH="80%"ALIGN="center"VALIGN="bottom"></TD><TDWIDTH="10%"ALIGN="right"VALIGN="bottom"><AHREF="kernel-thread-create.html"ACCESSKEY="N">Next</A></TD></TR></TABLE><HRALIGN="LEFT"WIDTH="100%"></DIV><H1><ANAME="KERNEL-SMP">SMP Support</H1><DIVCLASS="REFNAMEDIV"><ANAME="AEN206"></A><H2>Name</H2>SMP&nbsp;--&nbsp;Support Symmetric Multiprocessing Systems</DIV><DIVCLASS="REFSECT1"><ANAME="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 ofhardware supported. These are described in <AHREF="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 theeCos kernel to support SMP operation.    </P></DIV><DIVCLASS="REFSECT1"><ANAME="KERNEL-SMP-STARTUP"></A><H2>System Startup</H2><P>The system startup sequence needs to be somewhat different on an SMPsystem, although this is largely transparent to application code. Themain startup takes place on only one CPU, called the primary CPU. Allother CPUs, the secondary CPUs, are either placed in suspended stateat reset, or are captured by the HAL and put into a spin as they startup. The primary CPU is responsible for copying the DATA segment andzeroing the BSS (if required), calling HAL variant and platforminitialization routines and invoking constructors. It then calls<TTCLASS="FUNCTION">cyg_start</TT> to enter the application. Theapplication may then create extra threads and other objects.      </P><P>It is only when the application calls<TTCLASS="FUNCTION">cyg_scheduler_start</TT> that the secondary CPUs areinitialized. This routine scans the list of available secondary CPUsand invokes <TTCLASS="FUNCTION">HAL_SMP_CPU_START</TT> to start eachCPU. Finally it calls an internal function<TTCLASS="FUNCTION">Cyg_Scheduler::start_cpu</TT> to enter the schedulerfor the primary CPU.      </P><P>Each secondary CPU starts in the HAL, where it completes any per-CPUinitialization before calling into the kernel at<TTCLASS="FUNCTION">cyg_kernel_cpu_startup</TT>. Here it claims thescheduler lock and calls<TTCLASS="FUNCTION">Cyg_Scheduler::start_cpu</TT>.      </P><P><TTCLASS="FUNCTION">Cyg_Scheduler::start_cpu</TT> is common to both theprimary and secondary CPUs. The first thing this code does is toinstall an interrupt object for this CPU's inter-CPU interrupt. Fromthis point on the code is the same as for the single CPU case: aninitial thread is chosen and entered.      </P><P>From this point on the CPUs are all equal, eCos makes no furtherdistinction between the primary and secondary CPUs. However, thehardware may still distinguish between them as far as interruptdelivery is concerned.      </P></DIV><DIVCLASS="REFSECT1"><ANAME="KERNEL-SMP-SCHEDULING"></A><H2>Scheduling</H2><P>To function correctly an operating system kernel must protect itsvital data structures, such as the run queues, from concurrentaccess. In a single CPU system the only concurrent activities to worryabout are asynchronous interrupts. The kernel can easily guard itsdata structures against these by disabling interrupts. However, in amulti-CPU system, this is inadequate since it does not block access byother CPUs.      </P><P>The eCos kernel protects its vital data structures using the schedulerlock. In single CPU systems this is a simple counter that isatomically incremented to acquire the lock and decremented to releaseit. If the lock is decremented to zero then the scheduler may beinvoked to choose a different thread to run. Because interrupts maycontinue to be serviced while the scheduler lock is claimed, ISRs arenot allowed to access kernel data structures, or call kernel routinesthat can. Instead all such operations are deferred to an associatedDSR routine that is run during the lock release operation, when thedata structures are in a consistent state.      </P><P>By choosing a kernel locking mechanism that does not rely on interruptmanipulation to protect data structures, it is easier to convert eCosto SMP than would otherwise be the case. The principal change needed tomake eCos SMP-safe is to convert the scheduler lock into a nestablespin lock. This is done by adding a spinlock and a CPU id to theoriginal counter.      </P><P>The algorithm for acquiring the scheduler lock is very simple. If thescheduler lock's CPU id matches the current CPU then it can just incrementthe counter and continue. If it does not match, the CPU must spin onthe spinlock, after which it may increment the counter and store itsown identity in the CPU id.      </P><P>To release the lock, the counter is decremented. If it goes to zerothe CPU id value must be set to NONE and the spinlock cleared.      </P><P>To protect these sequences against interrupts, they must be performedwith interrupts disabled. However, since these are very short codesequences, they will not have an adverse effect on the interruptlatency.      </P><P>Beyond converting the scheduler lock, further preparing the kernel forSMP is a relatively minor matter. The main changes are to convertvarious scalar housekeeping variables into arrays indexed by CPUid. These include the current thread pointer, the need_rescheduleflag and the timeslice counter.      </P><P>At present only the Multi-Level Queue (MLQ) scheduler is capable ofsupporting SMP configurations. The main change made to this scheduleris to cope with having several threads in execution at the sametime. Running threads are marked with the CPU that they are executing on.When scheduling a thread, the scheduler skips past any running threadsuntil it finds a thread that is pending. While not a constant-timealgorithm, as in the single CPU case, this is still deterministic,since the worst case time is bounded by the number of CPUs in thesystem.      </P><P>A second change to the scheduler is in the code used to decide whenthe scheduler should be called to choose a new thread. The schedulerattempts to keep the <SPANCLASS="PROPERTY">n</SPAN> CPUs running the<SPANCLASS="PROPERTY">n</SPAN> highest priority threads. Since an event orinterrupt on one CPU may require a reschedule on another CPU, theremust be a mechanism for deciding this. The algorithm currentlyimplemented is very simple. Given a thread that has just been awakened(or had its priority changed), the scheduler scans the CPUs, startingwith the one it is currently running on, for a current thread that isof lower priority than the new one. If one is found then a rescheduleinterrupt is sent to that CPU and the scan continues, but now usingthe current thread of the rescheduled CPU as the candidate thread. Inthis way the new thread gets to run as quickly as possible, hopefullyon the current CPU, and the remaining CPUs will pick up the remaininghighest priority threads as a consequence of processing the rescheduleinterrupt.      </P><P>The final change to the scheduler is in the handling oftimeslicing. Only one CPU receives timer interrupts, although all CPUsmust handle timeslicing. To make this work, the CPU that receives thetimer interrupt decrements the timeslice counter for all CPUs, notjust its own. If the counter for a CPU reaches zero, then it sends atimeslice interrupt to that CPU. On receiving the interrupt thedestination CPU enters the scheduler and looks for another thread atthe same priority to run. This is somewhat more efficient thandistributing clock ticks to all CPUs, since the interrupt is onlyneeded when a timeslice occurs.      </P><P>All existing synchronization mechanisms work as before in an SMPsystem. Additional synchronization mechanisms have been added toprovide explicit synchronization for SMP, in the form of<AHREF="kernel-spinlocks.html">spinlocks</A>.      </P></DIV><DIVCLASS="REFSECT1"><ANAME="KERNEL-SMP-INTERRUPTS"></A><H2>SMP Interrupt Handling</H2><P>The main area where the SMP nature of a system requires specialattention is in device drivers and especially interrupt handling. Itis quite possible for the ISR, DSR and thread components of a devicedriver to execute on different CPUs. For this reason it is much moreimportant that SMP-capable device drivers use the interrupt-relatedfunctions correctly. Typically a device driver would use the driverAPI rather than call the kernel directly, but it is unlikely thatanybody would attempt to use a multiprocessor system without thekernel package.      </P><P>Two new functions have been added to the Kernel APIto do <AHREF="kernel-interrupts.html#KERNEL-INTERRUPTS-SMP">interruptrouting</A>: <TTCLASS="FUNCTION">cyg_interrupt_set_cpu</TT> and<TTCLASS="FUNCTION">cyg_interrupt_get_cpu</TT>. Although not currentlysupported, special values for the cpu argument may be used in futureto indicate that the interrupt is being routed dynamically or isCPU-local. Once a vector has been routed to a new CPU, all otherinterrupt masking and configuration operations are relative to thatCPU, where relevant.      </P><P>There are more details of how interrupts should be handled in SMPsystems in <AHREF="devapi-smp-support.html">the Section called <I>SMP Support</I> in Chapter 18</A>.      </P></DIV><DIVCLASS="NAVFOOTER"><HRALIGN="LEFT"WIDTH="100%"><TABLESUMMARY="Footer navigation table"WIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><TDWIDTH="33%"ALIGN="left"VALIGN="top"><AHREF="kernel-overview.html"ACCESSKEY="P">Prev</A></TD><TDWIDTH="34%"ALIGN="center"VALIGN="top"><AHREF="ecos-ref.html"ACCESSKEY="H">Home</A></TD><TDWIDTH="33%"ALIGN="right"VALIGN="top"><AHREF="kernel-thread-create.html"ACCESSKEY="N">Next</A></TD></TR><TR><TDWIDTH="33%"ALIGN="left"VALIGN="top">Kernel Overview</TD><TDWIDTH="34%"ALIGN="center"VALIGN="top"><AHREF="kernel.html"ACCESSKEY="U">Up</A></TD><TDWIDTH="33%"ALIGN="right"VALIGN="top">Thread creation</TD></TR></TABLE></DIV></BODY></HTML>

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -