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.
>
>
Just a note to say glibc is getting better wrt to locking.
Compare the results and trival test program here:
http://lkml.org/lkml/2001/12/7/75
That showed that for glibc 2.2.4, getc & putc
were 669% slower than the unlocked versions.
4 years later and with 2.3.5-1ubuntu1, getc & putc
are only 230% slower than the unlocked versions:
$ dd bs=1MB count=100 if=/dev/zero | ./locked >/dev/null
100000000 bytes transferred in 3.709362 seconds (26958813 bytes/sec)
$ dd bs=1MB count=100 if=/dev/zero | ./unlocked >/dev/null
100000000 bytes transferred in 1.602427 seconds (62405339 bytes/sec)
Pádraig.
-
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]
