In article <20001010113426.B12032@pcep-jamie.cern.ch>,
Jamie Lokier <lk@tantalophile.demon.co.uk> wrote:
>Linus Torvalds wrote:
>> You can also still do the stack pointer plaything by just using
>> indirection: and when you context switch you switch the pointer around at
>> the base of the per-cpu interrupt stack.
>
>Indirection, à la "current = *(stack & ~8191)" might not be a bad idea
>in general. As Ralf Baechle noted, having all the task structs at the
>same offset isn't good for the cache.
Well, indirection is worse. You get a cache killer there too, and added
to that your "current" lookup is just noticeably slower even without any
cache issues..
Also, there's a very simple rule of thumb that a lot of otherwise smart
people forget: hardware gets better.
In particular, direct-mapped caches basically do not exist any more in
any reasonable CPU. Sure, the L1 is still direct-mapped on some setups,
but (a) that's going away, and (b) if the CPU is reasonable the only
reason for this is that the L1 is really close and really fast, and the
L2 is good.
With CPU technology of today, any good CPU architect will work _hard_ at
making cache misses less likely, and there are absolutely no signs of
this changing - rather the reverse. Which means that you should expect
caches to go from the current four-way to eigth and more (with the L1
possibly staying at direct or two-way, but with low latency for a L2
miss).
Yes, it's "expensive" in area and in cycle time, but it's less expensive
than missing more. And most work-loads of today are not well-behaved
fortran stuff, so there are no longer any excuses for cache coloring and
trying to hide bad hardware that way.
Finally, most of the uses of "current" are _not_ of the type where you
look at multiple task structures in a row. The scheduler is in fact
pretty much the only case that this really happens in (oh, "wakeup()" can do it,
but if you have multiple processes waiting non-exclusively on a wakeup,
you have _other_ performance problems).
In the end it hasn't been much of a problem in Linux (scheduler
performance issues have tended to be _much_ more about avoiding
unnecessary scheduling and selecting the _right_ process than about
trying to avoid two cache misses).
I'm personally convinced that anybody who would try to make "current"
lookup more complicated to get cache coloring effects is looking at a
losing proposition - you may find machines where it would win, but never
in the long run. Give it up.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:15 EST