On Mon, 31 Jan 2000, Michael Schulz wrote:
> Stephen C. Tweedie:
> > That's why if you have a background task and two interactive tasks on a
> > 2-CPU machine, you really cannot avoid the background task jumping
> > between CPUs unless you are willing to leave a CPU idle at times (and
> > that, in general, is a very bad thing to do.)
>
> Yea, that's what the comments in sched.c say as well. But I
> seriously doubt that. Letting the background process jump pollutes
> the caches. That hurts more than letting the interactive process
> pass and keep the background process once asleep to wait for its
> home cpu. The affinity patch seems to be winner here. Didn't try
> it jet ;)
Depending on the workload, you might well be right here.
Having the background task repopulate the cache on its
new CPU is costing the other CPU (where our foreground
task is running) a lot of memory bandwidth...
We should think up a nice algorithm to make sure this
situation doesn't happen too often.
cheers,
Rik
-- The Internet is not a network of computers. It is a network of people. That is its real strength.- 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:05 EST