URL
https://opencores.org/ocsvn/openrisc/openrisc/trunk
Subversion Repositories openrisc
[/] [openrisc/] [trunk/] [rtos/] [ecos-2.0/] [doc/] [html/] [ref/] [kernel-characterization.html] - Rev 577
Go to most recent revision | Compare with Previous | Blame | View Log
<!-- 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
> Go to most recent revision | Compare with Previous | Blame | View Log