Re: Strange scheduling behavoir in SMP (kernel 2.2.14)

From: Michael Schulz (michael_schulz@public.uni-hamburg.de)
Date: Wed Feb 02 2000 - 04:29:34 EST


Mark Christiansen:
> How many cache misses does it take to compare with the cost of
> moving a process?
Yes. That's the question we want to answer cheaply in the scheduler.

But there's a question before the one above: how can I count cache
misses? Or how do I know the amount of code a process has in
cache?

If we cannot answer these questions because the hardware does not
provide this information then can we use a related heuristic? CPU
affinity was one mentioned some days ago and has already been
implemented. Has someone some results and experiences with that
idea? Please tell me!

One thing which bothered me about CPU affinity is, that it referes the
problem of cache misses as a kind of substitutional heuristic. As far
as I understood, it relys on the implication that if the affinitiy is
high then some code fragments most propably still are cached.

(Are there any references to this heuristic?)

So I thought that this might be of the way in some cases, that the
propability of cache misses still could be very high. For example
let's have a process which a couple of busy loops located quite at
different parts of the code. Then it kicks itself out of the cache,
which is OK from the viewpoint of the OS, and it might be optimizable
from the viewpoint of the process. Second situation: a process is
moved out of the cache by a number of other processes which run
simutanously in the box. This is a most natural situation as
well. They all want the honey pot.

BUT is it true that in both cases the affinity of the process in
question still is high, in oder to let them stay on their home cpu,
despite the fact that moving them has become _cheaper_ as they aren't
occupying cache any more ??? Affinity lets the process settle into the
cache again but moving it was definitly possible after a while.

Ergo, we obviously did not solve the problem here and we might do
better if we knew the footprint in cache a process has _now_ that we
have to answer Marks question in the scheduler.

I think having affinity is better than not to but theoreticaly (urgs)
there could even be a stronger heuristic. That's want I wanted to say.

So does the affinity thing behave the way I understood so far?

Here are even more questionmarks for you which open another field of
speculation and half knowledge I want to present to you;): Some
hardware does a kind of code prefetching. Do we work against that
sometimes? Is this extra feature of cpus controlable in order to let
it cooperate productively in the scheduler?

        Micha.

-- 
-- linux fuses brains
-- Michael Schulz, NatS - Uni Hamburg

- 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 Feb 07 2000 - 21:00:07 EST