Horst von Brand wrote:
> Steve Underwood <steveu@coppice.org> said:
> > Robert Dinse wrote:
>
> [...]
>
> > > Since the scheduler is adaptive, the new code, other than the
> > > test, is only going to executed under the heavy load conditions.
> > > Surely the test isn't 1kbyte or anywhere close to it?
>
> > A partially good point, but flawed.
>
> > In the reasonable load case most of the new code won't necessarily get
> > into the cache, so it should have little impact.
>
> But one instruction more to fetch from RAM is a _huge_ cost, relatively
> speaking. There is also the cost of making sure this whole machinery works
> right each time it is tweaked.
I quite agree. I didn't choose my words very well.
> > Now consider the high load case. A high load means the machine is being
> > crippled by multiple number crunching activities creating a compute
> > requirement beyond the system's reasonable means. [...]
>
> And this being so, no amount of tweaking will fix it. Leave it alone, that
> is simpler and has the same result: You need a a bigger machine.
Well, yes and no. If your machine performs general server activities you are
correct. If it exists to perform number crunching jobs it will never be big
enough. It will always be compute bound. The thing is, you should never allow
it to run more than one compute bound job per processor at any time. If you
do, the cache sloshing just makes it much slower.
I intended my previous message to talk about this, and how attacking the cache
sloshing would pay far greater dividends than any tweaking of the scheduler. I
ended up thinking out loud, and hit send before adequately reviewing the
pertinence of what I wrote. My C is OK until 4AM, but my English falls apart
by midnight!
Steve
-
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/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:24 EST