Messages in this thread | | | Date | Fri, 19 Feb 1999 12:50:07 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: 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/
| |