Messages in this thread | | | Date | Wed, 23 Nov 2005 16:02:37 -0700 | From | "Jeff V. Merkey" <> | Subject | Re: [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. > >
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 majordomo@vger.kernel.org >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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |