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]
