📄 kernel-characterization.html
字号:
>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
>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -