Ingo Molnar <[EMAIL PROTECTED]> writes: > thanks for the testing. The important result is that nice--20 > performance is roughly the same as SCHED_ISO. This somewhat > reduces the urgency of the introduction of SCHED_ISO.
Doing more runs and a more thorough analysis has driven me to a different conclusion. The important result is that *neither* nice-20 *nor* SCHED_ISO work properly in their current forms. For further comparison, I booted an old 2.4.19 kernel with Andrew Morton's low-latency patches and ran the same test SCHED_FIFO, with and without background compiles. The results were roughly the same as SCHED_FIFO on 2.6.11-rc1... http://www.joq.us/jack/benchmarks/2.4ll-fifo http://www.joq.us/jack/benchmarks/2.4ll-fifo+compile In addition, I extracted some across the board information by grepping for key results. Looking at these numbers in aggregate paints a pretty convincing picture that neither of the new scheduler prototypes are performing adequately compared to SCHED_FIFO on either 2.4ll or 2.6. http://www.joq.us/jack/benchmarks/cycle_max.log http://www.joq.us/jack/benchmarks/delay_max.log http://www.joq.us/jack/benchmarks/xrun_count.log Looking at delay_max broken down by directory is particularly striking. Below, I grouped the values by scheduling class to show the striking differences. These kinds of worst-case numbers are what realtime applications designers are generally most interested in... ============= SCHED_FIFO ============== ...benchmarks/2.4ll-fifo... Delay Maximum . . . . . . . . : 823 usecs Delay Maximum . . . . . . . . : 303 usecs ...benchmarks/2.4ll-fifo+compile... Delay Maximum . . . . . . . . : 926 usecs Delay Maximum . . . . . . . . : 663 usecs ...benchmarks/sched-fifo... Delay Maximum . . . . . . . . : 347 usecs Delay Maximum . . . . . . . . : 277 usecs Delay Maximum . . . . . . . . : 246 usecs ...benchmarks/sched-fifo+compile... Delay Maximum . . . . . . . . : 285 usecs Delay Maximum . . . . . . . . : 269 usecs Delay Maximum . . . . . . . . : 277 usecs Delay Maximum . . . . . . . . : 569 usecs Delay Maximum . . . . . . . . : 461 usecs ============= nice(-20) ============== ...benchmarks/nice-20... Delay Maximum . . . . . . . . : 13818 usecs Delay Maximum . . . . . . . . : 155637 usecs Delay Maximum . . . . . . . . : 487 usecs Delay Maximum . . . . . . . . : 160328 usecs Delay Maximum . . . . . . . . : 495328 usecs ...benchmarks/nice-20+compile... Delay Maximum . . . . . . . . : 183083 usecs Delay Maximum . . . . . . . . : 5976 usecs Delay Maximum . . . . . . . . : 18155 usecs Delay Maximum . . . . . . . . : 557 usecs ============= SCHED_ISO ============== ...benchmarks/sched-iso... Delay Maximum . . . . . . . . : 21410 usecs Delay Maximum . . . . . . . . : 36830 usecs Delay Maximum . . . . . . . . : 4062 usecs ...benchmarks/sched-iso+compile... Delay Maximum . . . . . . . . : 98909 usecs Delay Maximum . . . . . . . . : 39414 usecs Delay Maximum . . . . . . . . : 40294 usecs Delay Maximum . . . . . . . . : 217192 usecs Delay Maximum . . . . . . . . : 156989 usecs Looked at this way, there really is no question. The new scheduler prototypes are falling short significantly. Could this be due to their lack of priority distinctions between realtime threads? Maybe. I can't say for sure. I'll be interested to see what happens when Con is ready for me to try his new priority-based SCHED_ISO prototype. On a different note, the fact that 2.6 is finally performing as well as 2.4+lowlat on this test represents significant progress. In fact, it performed slightly better (I don't know whether that improvement is statistically significant). Congratulations to all who had a hand in making this happen! -- joq - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
