[lkml]   [1999]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: More new schedule() results ...

    >this is what i suspected. If we are switching 450 threads that also do
    >some real work then we are trashing the cache _badly_ already, so pure
    >scheduling costs will not matter at all. Most systems (even loaded
    >servers) have typically less than 5 runnable processes. So those systems
    >will see 15% scheduling slowdown. Some applications might use many threads
    >- for those cases your patch is a nice improvement.

    Another couple of points.

    1) Even with the two tasks sample the 15 % slodown is not evident
    because the switching rate is statistically low.

    2) My algo use the _same_ _sematics_ used by the old one but do it faster.

    Probably You know better then me how many time schedule() is called in a
    Linux workstation ( system calls ).
    Lowering the time the cpu execute schedule() is not as lowering user mode
    code because schedule() code is mostly interrupt protected.
    This means a low speed in acknoledging IRQ and hence a worse system response
    to events.

    This is all,


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:52    [W:0.021 / U:3.792 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site