Re: PREEMPT_RT vs I-PIPE: the numbers, part 2

Ingo Molnar
2005-06-22T18:18:47Z

* Karim Yaghmour <karim@opersys.com> wrote:

>
> Ingo Molnar wrote:
> >>you could try the LPPTEST kernel driver and testlpp utility i
> >>integrated into the -RT patchset. It avoids target-side latencies
> >>almost completely. Especially since you had problems with parallel
> >>interrupts you should give it a go and compare the results.
> >
> >
> > correction: logger-side latencies are avoided.
>
> Sorry, I don't see this. I've just looked at lpptest.c and it does
> practically the same thing LRTBF is doing, have a look for yourself
> at the code in LRTBF.

you should take another look. The crutial difference is that AFAICS
lrtbf is using interrupts on _both_ the logger and the target side.
lpptest only uses interrupts on the target side (that is what we are
measuring), but uses polling _with all interrupts disabled_ on the
logger side. This makes things much more reliable, as it's not some
complex mix of two worst-case latencies, but a small constant overhead
on the logger side and the worst-case latency on the target side. This
also means i can run whatever lpptest version on the logger side, i dont
have to worry about its latencies because there are none that are
variable.

> In fact lpptest.c is probably running at a higher cost on the logger
> since it executes a copy_to_user() for every single data point
> collected. [...]

logger-side overhead does not matter at all, and the 8 bytes copy is not
measured in the overhead. (it is also insignificant.)

> [...] In the case of the LRTBF, we just buffer the results in a
> preallocated buffer and then read them all at once after the testrun.
>
> Unless I'm missing something, there is nothing done in lpptest that we
> aren't already doing on either side, logger-side latencies included.
>
> As for the interrupt problems, they were pilot error. They disappeared
> once the APIC was enabled. That's therefore a non-issue.

well, LPPTEST works just fine with the i8259A PIC too. (which is much
more common in embedded setups than IO-APICs)

Ingo