lkml.org 
[lkml]   [2005]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] [request for inclusion] Realtime LSM
    From
    Date

    > Ingo Molnar <mingo@elte.hu> writes:
    >> could you try the patch below? The above patch wasnt enough. With the
    >> patch below we turn off the starvation limits for nice --20 tasks only.
    >> This is still a hack only. If we cannot make nice --20 perform like
    >> RT-prio-1 then there's some problem with SCHED_OTHER scheduling.

    I made your suggested sched.c change. It works much better. I was
    not able to modify JACK (for reasons explained in an earlier message).
    So, this test has the same interference problems with non-realtime
    threads. Of course, I don't know for sure that they are the source of
    our xruns and long delays, but that's my suspicion.

    I didn't have the same problems with normal processes being
    unresponsive (compared to the previous sched.c patch). The test ran
    normally, with about the same results we saw before for the nice --20
    experiments.

    *** Terminated Sat Jan 15 18:15:13 CST 2005 ***
    ************* SUMMARY RESULT ****************
    Total seconds ran . . . . . . : 300
    Number of clients . . . . . . : 20
    Ports per client . . . . . . : 4
    Frames per buffer . . . . . . : 64
    *********************************************
    Timeout Count . . . . . . . . :( 1)
    XRUN Count . . . . . . . . . : 47
    Delay Count (>spare time) . . : 0
    Delay Count (>1000 usecs) . . : 0
    Delay Maximum . . . . . . . . : 500544 usecs
    Cycle Maximum . . . . . . . . : 1086 usecs
    Average DSP Load. . . . . . . : 36.1 %
    Average CPU System Load . . . : 8.2 %
    Average CPU User Load . . . . : 26.3 %
    Average CPU Nice Load . . . . : 0.0 %
    Average CPU I/O Wait Load . . : 0.4 %
    Average CPU IRQ Load . . . . : 0.7 %
    Average CPU Soft-IRQ Load . . : 0.0 %
    Average Interrupt Rate . . . : 1703.3 /sec
    Average Context-Switch Rate . : 11600.6 /sec
    *********************************************

    I think this means the starvation test was not the problem. So far,
    I've seen no proof that there is any problem with the 2.6.10
    scheduler, just some evidence that nice --20 does not work for
    multi-threaded realtime audio.

    If someone can suggest a way to run certain threads of a process with
    a different nice value than the others, I can probably hack that into
    JACK in some crude way. That should tell us whether my intuition is
    right about the source of scheduling interference.

    Otherwise, I'm out of ideas at the moment. I don't think SCHED_RR
    will be any different from SCHED_FIFO in this test. Even if it were,
    I'm not sure what that would prove.
    --
    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:0.023 / U:31.448 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site