[lkml]   [2000]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Calling current() from interrupt context
    In article <>,
    Jamie Lokier <> 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

    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:39    [W:0.022 / U:47.468 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site