> 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/