linux-kernel - Re: first little problem with private futexes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <46509DE8.3060308@cosmosbay.com>
Date:	Sun, 20 May 2007 21:13:44 +0200
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Ulrich Drepper <drepper@...il.com>
CC:	Linux Kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: first little problem with private futexes

Ulrich Drepper a écrit :
> On 5/20/07, Eric Dumazet <dada1@...mosbay.com> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/