Re: [patch] SMP alternatives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux