![]() | ||||||||||
Messages in this thread |
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/ | |||||||||
| Last update: 2005-06-30 14:53 [from the cache] ©2003-2008 | ||||||||||