lkml.org 
[lkml]   [2005]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling
    From
    Date
    Ingo Molnar <mingo@elte.hu> 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 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-03-22 14:09    [W:4.788 / U:0.204 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site