Re: [patch] SMP alternatives

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

 



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.

Using self modifying code stubs will work, and Intel's architecture will support it. This would be faster than waiting 2-3 years for Intel to spin a processor rev. NetWare did something similair with
global branch tables for memory protection.


J


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.

		Linus
-
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/


-
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