Messages in this thread | | | Date | Thu, 25 Feb 1999 19:56:48 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: 2.2.2: 2 thumbs up from lm |
| |
On Thu, 25 Feb 1999, Richard Gooch wrote:
> I wasn't thinking in terms of long run queues, actually. Well, not > hugely long like dozens of tasks. Even a with a few tasks, thread > switching is measurably worse due to aliasing. [...]
the PII L1 cache is 16K and is 4-ways associative. This means the first time we have a _chance_ to get cachelines kicked out is with 5 running threads. There is no way you can place 4 task_structs to be misaligned. And chances are almost zero to get a collision in the 512K+ L2 cache.
> I don't see your point about penalising the "common, few threads" > case, though. To me it looks like it improves performance > *always*. Where is the performance hit?
the (obvious i think) cost is in the indirection of the 'outsourced' runqueue (well, scheduling) part of task_struct. Think of it this way: you are basically doing the CPU's job, you are slightly fixing up the cache architecture via introducing one more indirection (and quite some added complexity).
-- mingo
- 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/
| |