Re: [RFC] Scheduler queue implementation ...

From: Davide Libenzi (
Date: Sun Dec 09 2001 - 19:57:29 EST

On Mon, 10 Dec 2001, Alan Cox wrote:

> > What we lose is the mm ( + 1) goodness() but the eventual cost of
> > switching mm is melted inside the long execution time ( 50-60 ms ) typical
> > of CPU bound tasks ( note that matching MMs does not mean matching cache
> > image ).
> The mm matching and keeping an mm on the same cpu is critical for a lot of
> applications (your 50ms execution time includes 2ms loading the cache from
> the other CPU in some cases). Keeping the same mms together on the processor
> is critical for certain platforms (eg ARM) but not for x86 so much.

Alan, you're mixing switch mm costs with cache image reload ones.
Note that equal mm does not mean matching cache image, at all.
I would say that they're completely unrelated.
By having only two queues maintain the implementation simple and solves
99% of common/extraordinary cases.
The cost of a tlb flush become "meaningful" for I/O bound tasks where
their short average run time is not sufficent to compensate the tlb flush
cost, and this is handled correctly/like-usual inside the I/O bound queue.

- Davide

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:16 EST