+++ /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
->Kernel Real-time Characterization</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="Interrupt Handling"
-HREF="kernel-interrupts.html"><LINK
-REL="NEXT"
-TITLE="RedBoot™ User's Guide"
-HREF="redboot.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-interrupts.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="redboot.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><H1
-><A
-NAME="KERNEL-CHARACTERIZATION">Kernel Real-time Characterization</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN2068"
-></A
-><H2
->Name</H2
->tm_basic -- Measure the performance of the eCos kernel</DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="KERNEL-CHARACTERIZATION-DESCRIPTION"
-></A
-><H2
->Description</H2
-><P
->When building a real-time system, care must be taken to ensure that
-the system will be able to perform properly within the constraints of
-that system. One of these constraints may be how fast certain
-operations can be performed. Another might be how deterministic the
-overall 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 will
-be how to compare it with possible alternatives. Most manufacturers of
-real-time systems publish performance numbers, ostensibly so that
-users can compare the different offerings. However, what these numbers
-mean and how they were gathered is often not clear. The values are
-typically measured on a particular piece of hardware, so in order to
-truly compare, one must obtain measurements for exactly the same set
-of 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 typically
-quite easy to measure and will be available for most systems. Second,
-the determinacy of the numbers; in other words how much the value
-might change depending on other factors within the system. This value
-is affected by a number of factors: how long interrupts might be
-masked, whether or not the function can be interrupted, even very
-hardware-specific effects such as cache locality and pipeline usage.
-It is very difficult to measure the determinacy of any given
-operation, but that determinacy is fundamentally important to proper
-overall characterization of a system.
- </P
-><P
->In the discussion and numbers that follow, three key measurements are
-provided. The first measurement is an estimate of the interrupt
-latency: this is the length of time from when a hardware interrupt
-occurs until its Interrupt Service Routine (ISR) is called. The second
-measurement is an estimate of overall interrupt overhead: this is the
-length of time average interrupt processing takes, as measured by the
-real-time clock interrupt (other interrupt sources will certainly take
-a different amount of time, but this data cannot be easily gathered).
-The third measurement consists of the timings for the various kernel
-primitives.
- </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="KERNEL-CHARACTERIZATION-METHODOLOGY"
-></A
-><H2
->Methodology</H2
-><P
->Key operations in the kernel were measured by using a simple test
-program which exercises the various kernel primitive operations. A
-hardware timer, normally the one used to drive the real-time clock,
-was used for these measurements. In most cases this timer can be read
-with quite high resolution, typically in the range of a few
-microseconds. For each measurement, the operation was repeated a
-number of times. Time stamps were obtained directly before and after
-the operation was performed. The data gathered for the entire set of
-operations was then analyzed, generating average (mean), maximum and
-minimum values. The sample variance (a measure of how close most
-samples are to the mean) was also calculated. The cost of obtaining
-the real-time clock timer values was also measured, and was subtracted
-from all other times.
- </P
-><P
->Most kernel functions can be measured separately. In each case, a
-reasonable number of iterations are performed. Where the test case
-involves a kernel object, for example creating a task, each iteration
-is performed on a different object. There is also a set of tests which
-measures the interactions between multiple tasks and certain kernel
-primitives. Most functions are tested in such a way as to determine
-the variations introduced by varying numbers of objects in the system.
-For example, the mailbox tests measure the cost of a 'peek' operation
-when the mailbox is empty, has a single item, and has multiple items
-present. In this way, any effects of the state of the object or how
-many 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 in
-question. These measurements do not adequately describe how the
-timings would be perturbed in a real system with multiple interrupting
-sources. Secondly, the possible aberration incurred by the real-time
-clock (system heartbeat tick) is explicitly avoided. Virtually all
-kernel functions have been designed to be interruptible. Thus the
-times presented are typical, but best case, since any particular
-function may be interrupted by the clock tick processing. This number
-is explicitly calculated so that the value may be included in any
-deadline calculations required by the end user. Lastly, the reported
-measurements were obtained from a system built with all options at
-their default values. Kernel instrumentation and asserts are also
-disabled for these measurements. Any number of configuration options
-can change the measured results, sometimes quite dramatically. For
-example, mutexes are using priority inheritance in these measurements.
-The numbers will change if the system is built with priority
-inheritance 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 program
-used, but rather by instrumenting the kernel itself. The raw number of
-timer ticks that elapse between the time the timer generates an
-interrupt and the start of the timer ISR is kept in the kernel. These
-values are printed by the test program after all other operations have
-been tested. Thus this should be a reasonable estimate of the
-interrupt latency over time.
- </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="KERNEL-CHARACTERIZATION-USING-MEASUREMENTS"
-></A
-><H2
->Using these Measurements</H2
-><P
->These measurements can be used in a number of ways. The most typical
-use will be to compare different real-time kernel offerings on similar
-hardware, another will be to estimate the cost of implementing a task
-using eCos (applications can be examined to see what effect the kernel
-operations will have on the total execution time). Another use would
-be to observe how the tuning of the kernel affects overall operation.
- </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="KERNEL-CHARACTERIZATION-INFLUENCES"
-></A
-><H2
->Influences on Performance</H2
-><P
->A number of factors can affect real-time performance in a system. One
-of the most common factors, yet most difficult to characterize, is the
-effect of device drivers and interrupts on system timings. Different
-device drivers will have differing requirements as to how long
-interrupts are suppressed, for example. The eCos system has been
-designed 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, since
-there is so much variability here, and indeed most device drivers will
-come from the end users themselves, these effects cannot be reliably
-measured. Attempts have been made to measure the overhead of the
-single interrupt that eCos relies on, the real-time clock timer. This
-should give you a reasonable idea of the cost of executing interrupt
-handling for devices.
- </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="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
-<TT
-CLASS="FILENAME"
->cyg/kernel/kapi.h</TT
->). There is a single main thread
-in the system that performs the various tests. Additional threads may
-be created as part of the testing, but these are short lived and are
-destroyed 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 thread
-will run in preference to a lower priority thread even though the
-priority value of the higher priority thread may be numerically less
-than that of the lower priority thread.
- </P
-><DIV
-CLASS="REFSECT2"
-><A
-NAME="KERNEL-CHARACTERIZATION-MEASURE-THREADS"
-></A
-><H3
->Thread Primitives</H3
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
->Create thread</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_thread_create()</TT
-> call.
-Each call creates a totally new thread. The set of threads created by
-this test will be reused in the subsequent thread primitive tests.
- </P
-></DD
-><DT
->Yield thread</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_thread_yield()</TT
-> call.
-For this test, there are no other runnable threads, thus the test
-should just measure the overhead of trying to give up the CPU.
- </P
-></DD
-><DT
->Suspend [suspended] thread</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_thread_suspend()</TT
-> call.
-A thread may be suspended multiple times; each thread is already
-suspended from its initial creation, and is suspended again.
- </P
-></DD
-><DT
->Resume thread</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_thread_resume()</TT
-> call.
-All of the threads have a suspend count of 2, thus this call does not
-make them runnable. This test just measures the overhead of resuming a
-thread.
- </P
-></DD
-><DT
->Set priority</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_thread_set_priority()</TT
->
-call. Each thread, currently suspended, has its priority set to a new
-value.
- </P
-></DD
-><DT
->Get priority</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_thread_get_priority()</TT
->
-call.
- </P
-></DD
-><DT
->Kill [suspended] thread</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_thread_kill()</TT
-> call.
-Each thread in the set is killed. All threads are known to be
-suspended before being killed.
- </P
-></DD
-><DT
->Yield [no other] thread</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_thread_yield()</TT
-> call
-again. This is to demonstrate that the
-<TT
-CLASS="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 <TT
-CLASS="FUNCTION"
->cyg_thread_resume()</TT
-> call
-again. In this case, the thread being resumed is lower priority than
-the main thread, thus it will simply become ready to run but not be
-granted the CPU. This test measures the cost of making a thread ready
-to run.
- </P
-></DD
-><DT
->Resume [runnable low priority] thread</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_thread_resume()</TT
-> call
-again. In this case, the thread being resumed is lower priority than
-the main thread and has already been made runnable, so in fact the
-resume call has no effect.
- </P
-></DD
-><DT
->Suspend [runnable] thread</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_thread_suspend()</TT
-> call
-again. In this case, each thread has already been made runnable (by
-previous tests).
- </P
-></DD
-><DT
->Yield [only low priority] thread</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_thread_yield()</TT
-> call.
-In this case, there are many other runnable threads, but they are all
-lower priority than the main thread, thus no thread switches will take
-place.
- </P
-></DD
-><DT
->Suspend [runnable->not runnable] thread</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_thread_suspend()</TT
-> call
-again. The thread being suspended will become non-runnable by this
-action.
- </P
-></DD
-><DT
->Kill [runnable] thread</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_thread_kill()</TT
-> call
-again. In this case, the thread being killed is currently runnable,
-but lower priority than the main thread.
- </P
-></DD
-><DT
->Resume [high priority] thread</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_thread_resume()</TT
-> call.
-The thread being resumed is higher priority than the main thread, thus
-a thread switch will take place on each call. In fact there will be
-two thread switches; one to the new higher priority thread and a
-second back to the test thread. The test thread exits immediately.
- </P
-></DD
-><DT
->Thread switch</DT
-><DD
-><P
->This test attempts to measure the cost of switching from one thread to
-another. Two equal priority threads are started and they will each
-yield to the other for a number of iterations. A time stamp is
-gathered in one thread before the
-<TT
-CLASS="FUNCTION"
->cyg_thread_yield()</TT
-> call and after the call in the
-other thread.
- </P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT2"
-><A
-NAME="KERNEL-CHARACTERIZATION-MEASURE-SCHEDULER"
-></A
-><H3
->Scheduler Primitives</H3
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
->Scheduler lock</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_scheduler_lock()</TT
-> call.
- </P
-></DD
-><DT
->Scheduler unlock [0 threads]</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_scheduler_unlock()</TT
->
-call. There are no other threads in the system and the unlock happens
-immediately after a lock so there will be no pending DSR’s to
-run.
- </P
-></DD
-><DT
->Scheduler unlock [1 suspended thread]</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_scheduler_unlock()</TT
->
-call. There is one other thread in the system which is currently
-suspended.
- </P
-></DD
-><DT
->Scheduler unlock [many suspended threads]</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_scheduler_unlock()</TT
->
-call. There are many other threads in the system which are currently
-suspended. The purpose of this test is to determine the cost of having
-additional threads in the system when the scheduler is activated by
-way of <TT
-CLASS="FUNCTION"
->cyg_scheduler_unlock()</TT
->.
- </P
-></DD
-><DT
->Scheduler unlock [many low priority threads]</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_scheduler_unlock()</TT
->
-call. There are many other threads in the system which are runnable
-but are lower priority than the main thread. The purpose of this test
-is to determine the cost of having additional threads in the system
-when the scheduler is activated by way of
-<TT
-CLASS="FUNCTION"
->cyg_scheduler_unlock()</TT
->.
- </P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT2"
-><A
-NAME="KERNEL-CHARACTERIZATION-MEASURE-MUTEX"
-></A
-><H3
->Mutex Primitives</H3
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
->Init mutex</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mutex_init()</TT
-> call. A
-number of separate mutex variables are created. The purpose of this
-test is to measure the cost of creating a new mutex and introducing it
-to the system.
- </P
-></DD
-><DT
->Lock [unlocked] mutex</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mutex_lock()</TT
-> call. The
-purpose of this test is to measure the cost of locking a mutex which
-is currently unlocked. There are no other threads executing in the
-system while this test runs.
- </P
-></DD
-><DT
->Unlock [locked] mutex</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mutex_unlock()</TT
-> call.
-The purpose of this test is to measure the cost of unlocking a mutex
-which is currently locked. There are no other threads executing in the
-system while this test runs.
- </P
-></DD
-><DT
->Trylock [unlocked] mutex</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mutex_trylock()</TT
-> call.
-The purpose of this test is to measure the cost of locking a mutex
-which is currently unlocked. There are no other threads executing in
-the system while this test runs.
- </P
-></DD
-><DT
->Trylock [locked] mutex</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mutex_trylock()</TT
-> call.
-The purpose of this test is to measure the cost of locking a mutex
-which is currently locked. There are no other threads executing in the
-system while this test runs.
- </P
-></DD
-><DT
->Destroy mutex</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mutex_destroy()</TT
-> call.
-The purpose of this test is to measure the cost of deleting a mutex
-from the system. There are no other threads executing in the system
-while this test runs.
- </P
-></DD
-><DT
->Unlock/Lock mutex</DT
-><DD
-><P
->This test attempts to measure the cost of unlocking a mutex for which
-there is another higher priority thread waiting. When the mutex is
-unlocked, the higher priority waiting thread will immediately take the
-lock. The time from when the unlock is issued until after the lock
-succeeds in the second thread is measured, thus giving the round-trip
-or circuit time for this type of synchronizer.
- </P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT2"
-><A
-NAME="KERNEL-CHARACTERIZATION-MEASURE-MAILBOX"
-></A
-><H3
->Mailbox Primitives</H3
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
->Create mbox</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mbox_create()</TT
-> call. A
-number of separate mailboxes is created. The purpose of this test is
-to measure the cost of creating a new mailbox and introducing it to
-the system.
- </P
-></DD
-><DT
->Peek [empty] mbox</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mbox_peek()</TT
-> call. An
-attempt is made to peek the value in each mailbox, which is currently
-empty. The purpose of this test is to measure the cost of checking a
-mailbox for a value without blocking.
- </P
-></DD
-><DT
->Put [first] mbox</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mbox_put()</TT
-> call. One
-item is added to a currently empty mailbox. The purpose of this test
-is to measure the cost of adding an item to a mailbox. There are no
-other threads currently waiting for mailbox items to arrive.
- </P
-></DD
-><DT
->Peek [1 msg] mbox</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mbox_peek()</TT
-> call. An
-attempt is made to peek the value in each mailbox, which contains a
-single item. The purpose of this test is to measure the cost of
-checking a mailbox which has data to deliver.
- </P
-></DD
-><DT
->Put [second] mbox</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mbox_put()</TT
-> call. A
-second item is added to a mailbox. The purpose of this test is to
-measure the cost of adding an additional item to a mailbox. There are
-no other threads currently waiting for mailbox items to arrive.
- </P
-></DD
-><DT
->Peek [2 msgs] mbox</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mbox_peek()</TT
-> call. An
-attempt is made to peek the value in each mailbox, which contains two
-items. The purpose of this test is to measure the cost of checking a
-mailbox which has data to deliver.
- </P
-></DD
-><DT
->Get [first] mbox</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mbox_get()</TT
-> call. The
-first item is removed from a mailbox that currently contains two
-items. The purpose of this test is to measure the cost of obtaining an
-item from a mailbox without blocking.
- </P
-></DD
-><DT
->Get [second] mbox</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mbox_get()</TT
-> call. The
-last item is removed from a mailbox that currently contains one item.
-The purpose of this test is to measure the cost of obtaining an item
-from a mailbox without blocking.
- </P
-></DD
-><DT
->Tryput [first] mbox</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mbox_tryput()</TT
-> call. A
-single item is added to a currently empty mailbox. The purpose of this
-test is to measure the cost of adding an item to a mailbox.
- </P
-></DD
-><DT
->Peek item [non-empty] mbox</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mbox_peek_item()</TT
-> call.
-A single item is fetched from a mailbox that contains a single item.
-The purpose of this test is to measure the cost of obtaining an item
-without disturbing the mailbox.
- </P
-></DD
-><DT
->Tryget [non-empty] mbox</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mbox_tryget()</TT
-> call. A
-single item is removed from a mailbox that contains exactly one item.
-The purpose of this test is to measure the cost of obtaining one item
-from a non-empty mailbox.
- </P
-></DD
-><DT
->Peek item [empty] mbox</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mbox_peek_item()</TT
-> call.
-An attempt is made to fetch an item from a mailbox that is empty. The
-purpose of this test is to measure the cost of trying to obtain an
-item when the mailbox is empty.
- </P
-></DD
-><DT
->Tryget [empty] mbox</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mbox_tryget()</TT
-> call. An
-attempt is made to fetch an item from a mailbox that is empty. The
-purpose of this test is to measure the cost of trying to obtain an
-item when the mailbox is empty.
- </P
-></DD
-><DT
->Waiting to get mbox</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mbox_waiting_to_get()</TT
->
-call. The purpose of this test is to measure the cost of determining
-how many threads are waiting to obtain a message from this mailbox.
- </P
-></DD
-><DT
->Waiting to put mbox</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mbox_waiting_to_put()</TT
->
-call. The purpose of this test is to measure the cost of determining
-how many threads are waiting to put a message into this mailbox.
- </P
-></DD
-><DT
->Delete mbox</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_mbox_delete()</TT
-> call.
-The purpose of this test is to measure the cost of destroying a
-mailbox and removing it from the system.
- </P
-></DD
-><DT
->Put/Get mbox</DT
-><DD
-><P
->In this round-trip test, one thread is sending data to a mailbox that
-is being consumed by another thread. The time from when the data is
-put into the mailbox until it has been delivered to the waiting thread
-is measured. Note that this time will contain a thread switch.
- </P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT2"
-><A
-NAME="KERNEL-CHARACTERIZATION-MEASURE-SEMAPHORE"
-></A
-><H3
->Semaphore Primitives</H3
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
->Init semaphore</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_semaphore_init()</TT
-> call.
-A number of separate semaphore objects are created and introduced to
-the system. The purpose of this test is to measure the cost of
-creating a new semaphore.
- </P
-></DD
-><DT
->Post [0] semaphore</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_semaphore_post()</TT
-> call.
-Each semaphore currently has a value of 0 and there are no other
-threads in the system. The purpose of this test is to measure the
-overhead cost of posting to a semaphore. This cost will differ if
-there is a thread waiting for the semaphore.
- </P
-></DD
-><DT
->Wait [1] semaphore</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_semaphore_wait()</TT
-> call.
-The semaphore has a current value of 1 so the call is non-blocking.
-The purpose of the test is to measure the overhead of
-“taking” a semaphore.
- </P
-></DD
-><DT
->Trywait [0] semaphore</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_semaphore_trywait()</TT
->
-call. The semaphore has a value of 0 when the call is made. The
-purpose of this test is to measure the cost of seeing if a semaphore
-can be “taken” without blocking. In this case, the answer
-would be no.
- </P
-></DD
-><DT
->Trywait [1] semaphore</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_semaphore_trywait()</TT
->
-call. The semaphore has a value of 1 when the call is made. The
-purpose of this test is to measure the cost of seeing if a semaphore
-can be “taken” without blocking. In this case, the answer
-would be yes.
- </P
-></DD
-><DT
->Peek semaphore</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_semaphore_peek()</TT
-> call.
-The purpose of this test is to measure the cost of obtaining the
-current semaphore count value.
- </P
-></DD
-><DT
->Destroy semaphore</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_semaphore_destroy()</TT
->
-call. The purpose of this test is to measure the cost of deleting a
-semaphore from the system.
- </P
-></DD
-><DT
->Post/Wait semaphore</DT
-><DD
-><P
->In this round-trip test, two threads are passing control back and
-forth by using a semaphore. The time from when one thread calls
-<TT
-CLASS="FUNCTION"
->cyg_semaphore_post()</TT
-> until the other thread
-completes its <TT
-CLASS="FUNCTION"
->cyg_semaphore_wait()</TT
-> is measured.
-Note that each iteration of this test will involve a thread switch.
- </P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT2"
-><A
-NAME="KERNEL-CHARACTERIZATION-MEASURE-COUNTERS"
-></A
-><H3
->Counters</H3
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
->Create counter</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_counter_create()</TT
-> call.
-A number of separate counters are created. The purpose of this test is
-to measure the cost of creating a new counter and introducing it to
-the system.
- </P
-></DD
-><DT
->Get counter value</DT
-><DD
-><P
->This test measures the
-<TT
-CLASS="FUNCTION"
->cyg_counter_current_value()</TT
-> call. The current
-value of each counter is obtained.
- </P
-></DD
-><DT
->Set counter value</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_counter_set_value()</TT
->
-call. Each counter is set to a new value.
- </P
-></DD
-><DT
->Tick counter</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_counter_tick()</TT
-> call.
-Each counter is “ticked” once.
- </P
-></DD
-><DT
->Delete counter</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_counter_delete()</TT
-> call.
-Each counter is deleted from the system. The purpose of this test is
-to measure the cost of deleting a counter object.
- </P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT2"
-><A
-NAME="KERNEL-CHARACTERIZATION-MEASURE-ALARMS"
-></A
-><H3
->Alarms</H3
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
->Create alarm</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_alarm_create()</TT
-> call. A
-number of separate alarms are created, all attached to the same
-counter object. The purpose of this test is to measure the cost of
-creating a new counter and introducing it to the system.
- </P
-></DD
-><DT
->Initialize alarm</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_alarm_initialize()</TT
->
-call. Each alarm is initialized to a small value.
- </P
-></DD
-><DT
->Disable alarm</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_alarm_disable()</TT
-> call.
-Each alarm is explicitly disabled.
- </P
-></DD
-><DT
->Enable alarm</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_alarm_enable()</TT
-> call.
-Each alarm is explicitly enabled.
- </P
-></DD
-><DT
->Delete alarm</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_alarm_delete()</TT
-> call.
-Each alarm is destroyed. The purpose of this test is to measure the
-cost of deleting an alarm and removing it from the system.
- </P
-></DD
-><DT
->Tick counter [1 alarm]</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_counter_tick()</TT
-> call. A
-counter is created that has a single alarm attached to it. The purpose
-of this test is to measure the cost of “ticking” a counter
-when it has a single attached alarm. In this test, the alarm is not
-activated (fired).
- </P
-></DD
-><DT
->Tick counter [many alarms]</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_counter_tick()</TT
-> call. A
-counter is created that has multiple alarms attached to it. The
-purpose of this test is to measure the cost of “ticking” a
-counter when it has many attached alarms. In this test, the alarms are
-not activated (fired).
- </P
-></DD
-><DT
->Tick & fire counter [1 alarm]</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_counter_tick()</TT
-> call. A
-counter is created that has a single alarm attached to it. The purpose
-of this test is to measure the cost of “ticking” a counter
-when it has a single attached alarm. In this test, the alarm is
-activated (fired). Thus the measured time will include the overhead of
-calling the alarm callback function.
- </P
-></DD
-><DT
->Tick & fire counter [many alarms]</DT
-><DD
-><P
->This test measures the <TT
-CLASS="FUNCTION"
->cyg_counter_tick()</TT
-> call. A
-counter is created that has multiple alarms attached to it. The
-purpose of this test is to measure the cost of “ticking” a
-counter when it has many attached alarms. In this test, the alarms are
-activated (fired). Thus the measured time will include the overhead of
-calling the alarm callback function.
- </P
-></DD
-><DT
->Alarm latency [0 threads]</DT
-><DD
-><P
->This test attempts to measure the latency in calling an alarm callback
-function. The time from the clock interrupt until the alarm function
-is called is measured. In this test, there are no threads that can be
-run, other than the system idle thread, when the clock interrupt
-occurs (all threads are suspended).
- </P
-></DD
-><DT
->Alarm latency [2 threads]</DT
-><DD
-><P
->This test attempts to measure the latency in calling an alarm callback
-function. The time from the clock interrupt until the alarm function
-is called is measured. In this test, there are exactly two threads
-which are running when the clock interrupt occurs. They are simply
-passing back and forth by way of the
-<TT
-CLASS="FUNCTION"
->cyg_thread_yield()</TT
-> call. The purpose of this test
-is to measure the variations in the latency when there are executing
-threads.
- </P
-></DD
-><DT
->Alarm latency [many threads]</DT
-><DD
-><P
->This test attempts to measure the latency in calling an alarm callback
-function. The time from the clock interrupt until the alarm function
-is called is measured. In this test, there are a number of threads
-which are running when the clock interrupt occurs. They are simply
-passing back and forth by way of the
-<TT
-CLASS="FUNCTION"
->cyg_thread_yield()</TT
-> call. The purpose of this test
-is to measure the variations in the latency when there are many
-executing threads.
- </P
-></DD
-></DL
-></DIV
-></DIV
-></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-interrupts.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="redboot.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Interrupt Handling</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="kernel.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->RedBoot™ User's Guide</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
projects / karo-tx-redboot.git / blobdiff