lkml.org 
[lkml]   [1999]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.2.1 scheduler behavior

    On Fri, 19 Feb 1999, Neil Conway wrote:

    > > In the scheduler, is the PROC_CHANGE_PENALTY is large enough, is it
    > > something else ?
    >
    > PROC_CHANGE_PENALTY is something that I've looked at, in fact I'm the
    > person who had it *reduced* in the late 2.1 series (it was causing
    > problems with interactive performance because it was just big enough to
    > cause bad behaviour).

    i've changed it back to 15 around pre9-2.2.0. Your original reasoning for
    reducing PROC_CHANGE_PENALTY was interactive feel, but this became a
    non-issue with my smp_reschedule patches, so i empirically adjusted
    PROC_CHANGE_PENALTY to maximize kernel compilation speed.

    > swaps CPU *every* timeslice on an x86, big deal - how long can it
    > possibly take on say a PII-512kB cache to refill the L2 cache
    > completely? A damn small percentage of 200ms I'll bet. [...]

    takes about 5 msecs on a Xeon with 1M cache, 2-3 usecs on a PII with 512M
    cache.

    > My guess is more like 5ms and that's being really generous. Older CPU's
    > have smaller L2 caches and probably shared ones anyway so it won't be
    > very important for them either.

    you are missing the point. threads switching between CPUs are quite
    common. If a thread is CPU-bound and it's the only thread then your
    example is the _best case_, not the worst case. The worst case is a
    webserver with spikes of load, having say 10-20 processes running at once,
    and heavy rescheduling between say 200 processes. Not accounting for cache
    affinity properly will kill performance in lots of CPU-bound cases.

    also, these 'only 5 msecs' are 2.5% of the CPU (we've done full kernel
    rewrites for substantially less performance ..), for _both_ CPUs in
    question. Also, in those 5 msecs we occupy the memory bus, which is a
    scarce resource as well.

    > then suddenly you may have a much larger portion of your timeslice
    > wasted with cache misses... But upping PROC_CHANGE_PENALTY probably

    but the whol point is moot i think, because 2.2.1 _has_ a high
    PROC_CHANGE_PENALTY.

    -- mingo


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:50    [W:0.020 / U:0.644 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site