On Wed, Nov 23, 2005 at 01:36:08PM -0800, Linus Torvalds wrote:
> But optimizing for a single _thread_ is not a lost game. I don't believe
> that threaded applications are necessarily going to take over all that
> much in a lot of areas. Sure, we'll have more threaded apps too, but we'll
> continue to have tons more of performance-critical non-threaded things
> like compilers etc.
>
> And _that_ is worth optimizing for. General libraries that have to be able
> to handle the threaded case dynamically, but that are often run with no
> shared memory anywhere.
>
> THAT is what I'd like to have CPU support for. Not for UP (it's going
> away), and not for the kernel (it's never single-threaded).
I don't think I see the point. This would let you optimize for the
"multi-threaded, but hasn't created any threads yet" or even
"multi-threaded, but not right now" cases. But those really aren't the
interesting case to optimize for - that's the equivalent of supporting
CPU hotplug.
The interesting case is when you know at static link time that the
library is single-threaded, or even at dynamic link time. And it's
easy enough at both of those times to handle this. In many cases glibc
doesn't, because it's valid to dlopen libpthread.so, but that could be
accomodated - a simple matter of software.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
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]
