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

[Ingo Molnar <mingo@elte.hu>]

* 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