Messages in this thread | | | Date | Sun, 9 Dec 2001 16:57:29 -0800 (PST) | From | Davide Libenzi <> | Subject | Re: [RFC] Scheduler queue implementation ... |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |