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.060 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site