Ulrich Drepper a écrit :
On 5/20/07, Eric Dumazet <[email protected]> wrote:
> 1. do nothing, always use the shared futexes. Not very attractive IMO
Why do you find this non attractive ?
How is it performance critical ?
You should know better than any other that the problem is not that the
problem itself is the only one affected. If threads terminate all
other programs and threads are affected since the global locks for the
shared futexes are needed. That's the case I'm concerned about. It's
not really about a single app creating many many threads over and over
again. It's about many apps which do use threads (and that number
will have to rise) starts and stop threads at a reasonable rate. It's
just one more unnecessary point of contact between concurrently
running apps.
Well, current private futex code still use global locks (one common hash table
were all waited futexes are queued, private or shared)
'Only' mmap_sem and inode/mm refcounter inc/dec are avoided.
My proposal of having separate namespace was hold, in order to get the
'private futexes' accepted in kernel.
So for the moment, I am not sure glibc should try to optimize CLEARTID operation.
-
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]
