Re: PREEMPT_RT and I-PIPE: the numbers, take 3

[Sven-Thorsten Dietrich <sdietrich@mvista.com>]

On Thu, 2005-06-30 at 18:17 +0200, Ingo Molnar wrote:
> * Paul E. McKenney <paulmck@us.ibm.com> wrote:
> 
> > > another point is that this test is measuring the overhead of PREEMPT_RT, 
> > > without measuring the benefit of the cost: RT-task scheduling latencies.  
> > > We know since the rtirq patch (to which i-pipe is quite similar) that we 
> > > can achieve good irq-service latencies via relatively simple means, but 
> > > that's not what PREEMPT_RT attempts to do. (PREEMPT_RT necessarily has 
> > > to have good irq-response times too, but much of the focus went to the 
> > > other aspects of RT task scheduling.)
> > 
> > Agreed, a PREEMPT_RT-to-IPIPE comparison will never be an 
> > apples-to-apples comparison.  Raw data will never be a substitute for 
> > careful thought, right?  ;-)
> 
> well, it could still be tested, since it's so easy: the dohell script is 
> already doing all of that as it runs rtc_wakeup - which runs a 
> SCHED_FIFO task and carefully measures wakeup latencies. If it is used 
> with 1024 Hz (the default) and it can be used in every test without 
> impacting the system load in any noticeable way.
> 

I use a parallel implementation that has acquired the name FRD 
(Fast Real Time Domain). 

It triggers off any IRQ, and measures time to get RT task(s) running.  

The objective is to measure periodic task performance for one or more
tasks of equal, ascending, or descending priorities. 

The first task is worken by IRQ, the other tasks wake each other and
either yield or preempt, depending on ascending or descending priority. 

Especially when one RT task wakes an RT task of higher priority,
interesting things happen.

Average and Worst-case Histograms are produced in /proc, for sleep time,
run time, task wake-up latency (preemption), inter-task switch, and
absolute latency from IRQ assertion (IRQ latency + preemption) if the
IRQ assertion time is available.

On many archs, a spare auto-resetting timer can be used for the IRQ
source. With the auto-rest timer, the rollover count is available
a-priori. 

This allows getting the absolute latency since IRQ assertion, i.e. time
since timer rollover. 

It is nice to get a feel for the combined impact of IRQ disable and
preemption on task response.

For portability, I have a hook into do_timer, and I acknowledge the
blind spot this creates, but like I said, you can use any IRQ and just
hook up your own way to get the IRQ-assert time stamps.

For a really scientific test, you can write an IRQ handler and a driver
to hook up an external signal generator, Cesium or GPS, and GPIB, or
what have you. Anything to drive the external time stamps into the
program, but that is an exercise for the developer.

If anyone is interested, I can update it for Ingo's latest RT tree and
send it out.

Sven




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/