[lkml]   [2005]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] SMP alternatives
    Bill Davidsen wrote:

    > 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.
    In 2-3 years we might actually see the hardware solution, maybee .... I
    am skeptical Intel will move quickly on it. A software solution will get
    out faster.

    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 23:48    [W:0.025 / U:12.304 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site