📄 kernel-characterization.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>Kernel Real-time Characterization</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="Interrupt Handling"HREF="kernel-interrupts.html"><LINKREL="NEXT"TITLE="RedBoot™ User's Guide"HREF="redboot.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-interrupts.html"ACCESSKEY="P">Prev</A></TD><TDWIDTH="80%"ALIGN="center"VALIGN="bottom"></TD><TDWIDTH="10%"ALIGN="right"VALIGN="bottom"><AHREF="redboot.html"ACCESSKEY="N">Next</A></TD></TR></TABLE><HRALIGN="LEFT"WIDTH="100%"></DIV><H1><ANAME="KERNEL-CHARACTERIZATION">Kernel Real-time Characterization</H1><DIVCLASS="REFNAMEDIV"><ANAME="AEN2068"></A><H2>Name</H2>tm_basic -- Measure the performance of the eCos kernel</DIV><DIVCLASS="REFSECT1"><ANAME="KERNEL-CHARACTERIZATION-DESCRIPTION"></A><H2>Description</H2><P>When building a real-time system, care must be taken to ensure thatthe system will be able to perform properly within the constraints ofthat system. One of these constraints may be how fast certainoperations can be performed. Another might be how deterministic theoverall behavior of the system is. Lastly the memory footprint (size)and unit cost may be important. </P><P>One of the major problems encountered while evaluating a system willbe how to compare it with possible alternatives. Most manufacturers ofreal-time systems publish performance numbers, ostensibly so thatusers can compare the different offerings. However, what these numbersmean and how they were gathered is often not clear. The values aretypically measured on a particular piece of hardware, so in order totruly compare, one must obtain measurements for exactly the same setof hardware that were gathered in a similar fashion. </P><P>Two major items need to be present in any given set of measurements.First, the raw values for the various operations; these are typicallyquite easy to measure and will be available for most systems. Second,the determinacy of the numbers; in other words how much the valuemight change depending on other factors within the system. This valueis affected by a number of factors: how long interrupts might bemasked, whether or not the function can be interrupted, even veryhardware-specific effects such as cache locality and pipeline usage.It is very difficult to measure the determinacy of any givenoperation, but that determinacy is fundamentally important to properoverall characterization of a system. </P><P>In the discussion and numbers that follow, three key measurements areprovided. The first measurement is an estimate of the interruptlatency: this is the length of time from when a hardware interruptoccurs until its Interrupt Service Routine (ISR) is called. The secondmeasurement is an estimate of overall interrupt overhead: this is thelength of time average interrupt processing takes, as measured by thereal-time clock interrupt (other interrupt sources will certainly takea different amount of time, but this data cannot be easily gathered).The third measurement consists of the timings for the various kernelprimitives. </P></DIV><DIVCLASS="REFSECT1"><ANAME="KERNEL-CHARACTERIZATION-METHODOLOGY"></A><H2>Methodology</H2><P>Key operations in the kernel were measured by using a simple testprogram which exercises the various kernel primitive operations. Ahardware timer, normally the one used to drive the real-time clock,was used for these measurements. In most cases this timer can be readwith quite high resolution, typically in the range of a fewmicroseconds. For each measurement, the operation was repeated anumber of times. Time stamps were obtained directly before and afterthe operation was performed. The data gathered for the entire set ofoperations was then analyzed, generating average (mean), maximum andminimum values. The sample variance (a measure of how close mostsamples are to the mean) was also calculated. The cost of obtainingthe real-time clock timer values was also measured, and was subtractedfrom all other times. </P><P>Most kernel functions can be measured separately. In each case, areasonable number of iterations are performed. Where the test caseinvolves a kernel object, for example creating a task, each iterationis performed on a different object. There is also a set of tests whichmeasures the interactions between multiple tasks and certain kernelprimitives. Most functions are tested in such a way as to determinethe variations introduced by varying numbers of objects in the system.For example, the mailbox tests measure the cost of a 'peek' operationwhen the mailbox is empty, has a single item, and has multiple itemspresent. In this way, any effects of the state of the object or howmany items it contains can be determined. </P><P>There are a few things to consider about these measurements. Firstly,they are quite micro in scale and only measure the operation inquestion. These measurements do not adequately describe how thetimings would be perturbed in a real system with multiple interruptingsources. Secondly, the possible aberration incurred by the real-timeclock (system heartbeat tick) is explicitly avoided. Virtually allkernel functions have been designed to be interruptible. Thus thetimes presented are typical, but best case, since any particularfunction may be interrupted by the clock tick processing. This numberis explicitly calculated so that the value may be included in anydeadline calculations required by the end user. Lastly, the reportedmeasurements were obtained from a system built with all options attheir default values. Kernel instrumentation and asserts are alsodisabled for these measurements. Any number of configuration optionscan change the measured results, sometimes quite dramatically. Forexample, mutexes are using priority inheritance in these measurements.The numbers will change if the system is built with priorityinheritance on mutex variables turned off. </P><P>The final value that is measured is an estimate of interrupt latency.This particular value is not explicitly calculated in the test programused, but rather by instrumenting the kernel itself. The raw number oftimer ticks that elapse between the time the timer generates aninterrupt and the start of the timer ISR is kept in the kernel. Thesevalues are printed by the test program after all other operations havebeen tested. Thus this should be a reasonable estimate of theinterrupt latency over time. </P></DIV><DIVCLASS="REFSECT1"><ANAME="KERNEL-CHARACTERIZATION-USING-MEASUREMENTS"></A><H2>Using these Measurements</H2><P>These measurements can be used in a number of ways. The most typicaluse will be to compare different real-time kernel offerings on similarhardware, another will be to estimate the cost of implementing a taskusing eCos (applications can be examined to see what effect the kerneloperations will have on the total execution time). Another use wouldbe to observe how the tuning of the kernel affects overall operation. </P></DIV><DIVCLASS="REFSECT1"><ANAME="KERNEL-CHARACTERIZATION-INFLUENCES"></A><H2>Influences on Performance</H2><P>A number of factors can affect real-time performance in a system. Oneof the most common factors, yet most difficult to characterize, is theeffect of device drivers and interrupts on system timings. Differentdevice drivers will have differing requirements as to how longinterrupts are suppressed, for example. The eCos system has beendesigned with this in mind, by separating the management of interrupts(ISR handlers) and the processing required by the interrupt(DSR—Deferred Service Routine— handlers). However, sincethere is so much variability here, and indeed most device drivers willcome from the end users themselves, these effects cannot be reliablymeasured. Attempts have been made to measure the overhead of thesingle interrupt that eCos relies on, the real-time clock timer. Thisshould give you a reasonable idea of the cost of executing interrupthandling for devices. </P></DIV><DIVCLASS="REFSECT1"><ANAME="KERNEL-CHARACTERIZATION-MEASURED-ITEMS"></A><H2>Measured Items</H2><P>This section describes the various tests and the numbers presented.All tests use the C kernel API (available by way of<TTCLASS="FILENAME">cyg/kernel/kapi.h</TT>). There is a single main threadin the system that performs the various tests. Additional threads maybe created as part of the testing, but these are short lived and aredestroyed between tests unless otherwise noted. The terminology“lower priority” means a priority that is less important,not necessarily lower in numerical value. A higher priority threadwill run in preference to a lower priority thread even though thepriority value of the higher priority thread may be numerically lessthan that of the lower priority thread. </P><DIVCLASS="REFSECT2"><ANAME="KERNEL-CHARACTERIZATION-MEASURE-THREADS"></A><H3>Thread Primitives</H3><P></P><DIVCLASS="VARIABLELIST"><DL><DT>Create thread</DT><DD><P>This test measures the <TTCLASS="FUNCTION">cyg_thread_create()</TT> call.Each call creates a totally new thread. The set of threads created bythis test will be reused in the subsequent thread primitive tests. </P></DD><DT>Yield thread</DT><DD><P>This test measures the <TTCLASS="FUNCTION">cyg_thread_yield()</TT> call.For this test, there are no other runnable threads, thus the testshould just measure the overhead of trying to give up the CPU. </P></DD><DT>Suspend [suspended] thread</DT><DD><P>This test measures the <TTCLASS="FUNCTION">cyg_thread_suspend()</TT> call.A thread may be suspended multiple times; each thread is alreadysuspended from its initial creation, and is suspended again. </P></DD><DT>Resume thread</DT><DD><P>This test measures the <TTCLASS="FUNCTION">cyg_thread_resume()</TT> call.All of the threads have a suspend count of 2, thus this call does notmake them runnable. This test just measures the overhead of resuming athread. </P></DD><DT>Set priority</DT><DD><P>This test measures the <TTCLASS="FUNCTION">cyg_thread_set_priority()</TT>call. Each thread, currently suspended, has its priority set to a newvalue. </P></DD><DT>Get priority</DT><DD><P>This test measures the <TTCLASS="FUNCTION">cyg_thread_get_priority()</TT>call. </P></DD><DT>Kill [suspended] thread</DT><DD><P>This test measures the <TTCLASS="FUNCTION">cyg_thread_kill()</TT> call.Each thread in the set is killed. All threads are known to besuspended before being killed. </P></DD><DT>Yield [no other] thread</DT><DD><P>This test measures the <TTCLASS="FUNCTION">cyg_thread_yield()</TT> callagain. This is to demonstrate that the<TTCLASS="FUNCTION">cyg_thread_yield()</TT> call has a fixed overhead,regardless of whether there are other threads in the system. </P></DD><DT>Resume [suspended low priority] thread</DT><DD><P>This test measures the <TTCLASS="FUNCTION">cyg_thread_resume()</TT> callagain. In this case, the thread being resumed is lower priority thanthe main thread, thus it will simply become ready to run but not begranted the CPU. This test measures the cost of making a thread readyto run. </P></DD><DT>Resume [runnable low priority] thread</DT><DD><P>This test measures the <TTCLASS="FUNCTION">cyg_thread_resume()</TT> callagain. In this case, the thread being resumed is lower priority thanthe main thread and has already been made runnable, so in fact theresume call has no effect. </P></DD><DT>Suspend [runnable] thread</DT><DD><P>This test measures the <TTCLASS="FUNCTION">cyg_thread_suspend()</TT> callagain. In this case, each thread has already been made runnable (byprevious tests). </P></DD><DT>Yield [only low priority] thread</DT><DD><P>This test measures the <TTCLASS="FUNCTION">cyg_thread_yield()</TT> call.In this case, there are many other runnable threads, but they are alllower priority than the main thread, thus no thread switches will takeplace. </P></DD><DT>Suspend [runnable->not runnable] thread</DT><DD><P>This test measures the <TTCLASS="FUNCTION">cyg_thread_suspend()</TT> callagain. The thread being suspended will become non-runnable by thisaction. </P></DD><DT>Kill [runnable] thread</DT><DD><P⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -