[lkml]   [2005]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] SMP alternatives
    Linus Torvalds wrote:
    > On Wed, 23 Nov 2005, Daniel Jacobowitz wrote:
    >>Why should we use a silicon based solution for this, when I posit that
    >>there are simpler and equally effective userspace solutions?
    > Name them.
    > In user space, doing things like clever run-time linking things is
    > actually horribly bad. It causes COW faults at startup, and/or makes the
    > compiler have to do indirections unnecessarily. Both of which actually
    > make caches less effective, because now processes that really effectively
    > do have exactly the same contents have them in different pages.
    > The other alternative (which apparently glibc actually does use) is to
    > dynamically branch over the lock prefixes, which actually works better:
    > it's more work dynamically, but it's much cheaper from a startup
    > standpoint and there's no memory duplication, so while it is the "stupid"
    > approach, it's actually better than the clever one.
    > The third alternative is to know at link-time that the process never does
    > anything threaded, but that needs more developer attention and
    > non-standard setups, and you _will_ get it wrong (some library will create
    > some thread without the developer even realizing). It also has the
    > duplicated library overhead (but at least now the duplication is just
    > twice, not "each process duplicates its own private pointer")
    > In short, there simply isn't any good alternatives. The end result is that
    > thread-safe libraries are always in practice thread-safe even on UP, even
    > though that serializes the CPU altogether unnecessarily.
    > I'm sure you can make up alternatives every time you hit one _particular_
    > library, but that just doesn't scale in the real world.
    > In contrast, the simple silicon support scales wonderfully well. Suddenly
    > libraries can be thread-safe _and_ efficient on UP too. You get to eat
    > your cake and have it too.

    I believe that a hardware solution would also accomodate the case where
    a program runs unthreaded for most of the processing, and only starts
    threads to do the final stage "report generation" tasks, where that
    makes sense. I don't believe that it helps in the case where init uses
    threads and then reverts to a single thread for the balance of the task.
    I can't think of anything which does that, so it's probably a
    non-critical corner case, or something the thread library could correct.

    -bill davidsen (
    "The secret to procrastination is to put things off until the
    last possible moment - but no longer" -me
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-11-28 20:53    [W:0.040 / U:0.412 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site