Re: [patch] SMP alternatives

["Jeff V. Merkey" <jmerkey@wolfmountaingroup.com>]

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/