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

["Paul E. McKenney" <paulmck@us.ibm.com>]

On Thu, Jun 30, 2005 at 06:17:26PM +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.

OK, I think that I finally understand what you are getting at -- and I
agree that it would be interesting to get latency measurements during the
actual lmbench runs.  However, if I understand correctly, you would want
roughly 1,000,000 latency measurements per lmbench run segment, which,
at 1024 Hz, would mean that each segment would take about 20 minutes.
A single lmbench run would then take many hours.

Is this really what you are getting at, or are you instead thinking
in terms of a single maximum-latency measurement covering the entire
lmbench run?

						Thanx, Paul