Messages in this thread |  | | From | (Linus Torvalds) | Subject | Re: Calling current() from interrupt context | Date | 10 Oct 2000 10:11:02 -0700 |
| |
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/
|  |