Dear All, just some details about our test.
We're actually dealing with Hard Real-Time problems (on x86) and we need
a way
to measure latencies in the IRQ handling kernel flow-paths.
We do not only need to measure the global (from the rise of an interrupt to
its
complete management) IRQ handling latency, but also the intermediate
(inter-function) latency values.
Our main objective is to evaluate Hard Real-Time feautures like
predictability
and time latency of IRQ response and IRQ management flow.
The kernel patch and the modules we have developed are in this
direction. The
patch allows us to measure (with little overhead) the execution times
between the main functions of the IRQ management flow. The modules read the
values we measure and place them into proc fs (in a more readable manner).
All time-values that are taken in the test are measured by reading the
TSC
register. Both the user space task and the kernel IRQ management flow-path
should
be bound on one processor, so to avoid discrepancies between different TSC
reads
on different CPUs.
The test is composed by a user space application which is waiting (with
a
blocking read on /dev/rtc) for RTC interrupts. We re-program the RTC device
to
launch interrupts at fixed frequency.
First fo all the user space test application set the real time priority
and
the real time policy SCHED_FIFO of the user task, then re-program the RTC
device
to launch interrupts at fixed frequency, and go to sleep waiting for RTC
interrupt.
Immediately after being woke up, the user space test application performs a
TSC read,
which constitutes the final measure of the IRQ management flow. Furthermore
this read
helps in telling kernel test latencies from spurious kernel inter-function
latencies
that may occur before the beginning of the test.
When the test is over the user apllication print the TSC values on the
console.
The patch we introduce in the kernel is able to record up to SAMPLES
samples
of inter-function latencies throughout the kernel path activated by RTC
interrupt management flow-path.
When the test is over, it is possible to read the inter-function latencies
(sampled in the kernel) through the proc fs, using "delta_read_irq"
and "irq_latencies_tsc" modules.
The "delta_read_irq" module is used to read the inter-function latencies
values
as the max, min, and total TSC cycles elapsed during the measured intervals.
With the "irq_latencies_tsc" module it is possible to read the TSC
values taken
inside IRQ flow-path functions.
By comparing these values with those obtained in the user space application,
one
can evaluate the whole latencies in the IRQ management flow (from the
arrival
of an hardware interrupt to the system, to the beginning of the test
application).
From the analisys of these results we can estimate the worst-case
latency and
the periodic jitter of an interrupt management flow-path.
We are also able to evaluate the required (re)scheduling effort and
inter-function
latencies.
The execution-jitter of the kernel paths we analyze is our measure to
evaluate the
predictability of "end-to-end" IRQ management (from the arrival of an
hardware interrupt
to the system, to the beginning of the test application).
The measured jitter is the standard deviation of the sampled latencies,
relatively to their mean.
At the moment, we make use of a spreadsheet to evaluate std.deviation,
worst,
best and average inter-function and end-to-end latencies. We build these
results
using 1000 sampled latency values (these values are obtained through the
module
"irq_latencies_tsc" and through the user space application).
It is important to note that the samples we measure in the kernel are in
clock cycle
unit and we have to transform them into time unit. The resolution of the
measure
heavily depends on the CPU frequency and on the time spent in reading the
TSC.
We have estimate for our measure a base definition of 10 ns.
The test is not yet automated, and doesn't respect LTP's
requirement. At the moment it is just a quite usable tool that is being
mainly use
as a base comparison between Vanilla kernel and RT kernel project
(http://www.eu.kernel.org/pub/linux/kernel/projects/rt/).
Regards,
Luca Recchia
2008/6/25 Subrata Modak <[EMAIL PROTECTED]>:
> On Thu, 2008-06-19 at 11:42 +0200, Christian Di Biagio wrote:
> > Luca is going to asnwer to your questions providing a web space for
> > code sharing.
> >
> > I encourage also a contribution of Andrea Bastoni, a PhD of the Prof.
> > D. P. Bovet (University of Rome Tor Vergata) on the matter.
>
> Christian/Lucas,
>
> Are we ready to move ahead with more information on this proposal ?
>
> Regards--
> Subrata
>
> >
> > Regards
> >
> > C.
> >
> >
> >
> > 2008/6/16 Subrata Modak <[EMAIL PROTECTED]>:
> > On Mon, 2008-06-16 at 10:29 +0200, Christian Di Biagio wrote:
> > > Dear,
> > >
> > > I would suggest you our contribution on Hard Real Time Linux
> > testing.
> > > Luca and me are working in collaboration with the
> > University of Rome
> > > "Sapienza" developing a complete RT Test suite. It is
> > built through
> > > a kernel patch and a user space application (like LTP) on
> > x86 arch.
> > > Test is simple: the RTC send periodic interrupts to the
> > user
> > > application, which previously has set-up the environment
> > (RTC
> > > frequency, priority, scheduling policy, etc.). During
> > testing the
> > > kernel patch (2.6.23.14) writes measures on the /proc fs.
> > Actually,
> > > we trace the whole IRQ chain.
> > >
> > >
> > > We would be very pleased to participate to your project
> > giving you our
> > > open source code.
> > >
> > > Please, let us know your feelings.
> >
> > Hi Christian,
> >
> > Thanks for considering LTP to contribute your test code for
> > Hard Real
> > Time Linux Testing. But, i would like to point out that we
> > already have
> > a very active community consisting of IBM, BULL, PENGUTRONIX
> > and others,
> > who are contributing to the growing development of Real Time
> > Linux
> > Testcases. Can you please have a look at the code that they
> > have
> > developed so far at:
> >
> > http://ltp.cvs.sourceforge.net/ltp/ltp/testcases/realtime/,
> >
> > I am looping in those developers and you, so that we can
> > discuss
> > further. We would like to know how does your tests differ from
> > the one
> > existing above, what and how would you like to tests, how
> > would you like
> > to interpret the results, what settings you would need to run
> > those
> > tests. Basically, what i would be interested to know is how
> > much your
> > tests will add value to LTP and the Linux community in
> > particular.
> >
> > Darren/Chirag/Sebastein,
> >
> > Can we initiate a discussion with Christian and lucas and try
> > to
> > understand their tests that they plan to contribute. If all of
> > you agree
> > after that, we can find a suitable place in LTP to integrate
> > their
> > tests.
> >
> > Regards--
> > Subrata
> >
> > >
> > > Regards
> > >
> > > Christian
> >
> >
>
>
test_irq.tar.bz2
Description: BZip2 compressed data
------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
