linux-kernel - Re: [patch 14/22] pollfs: pollable futex

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <a36005b50705030646v5b729838pe8dc7b91dc9bee2b@mail.gmail.com>
Date:	Thu, 3 May 2007 06:46:22 -0700
From:	"Ulrich Drepper" <drepper@...il.com>
To:	"Davide Libenzi" <davidel@...ilserver.org>
Cc:	"Davi Arnaut" <davi@...ent.com.br>,
	"Eric Dumazet" <dada1@...mosbay.com>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [patch 14/22] pollfs: pollable futex

On 5/2/07, Davide Libenzi <davidel@...ilserver.org> wrote:
> 99% of the fds you'll find inside an event loop you care to scale about,
> are *already* fd based.

You are missing the point.  To get acceptable behavior of the wakeup
it is necessary with this approach to open one descriptor _per thread_
for a futex.  Otherwise all threads get woken upon FUTEX_WAKE.

This also means you need individual epoll sets for each thread.  You
cannot share them anymore among all the threads in the process.

> On top of that, those fds are very cheap in terms of memory

They might be when they are counted in dozens.  But here we are
talking about the possible need to use thousands of additional file
descriptors.  If they are so cheap to allow thousands of descriptors
with ease, why would the rlimit for files default to a small number
(1024 on Fedora right now)?

> And this approach is not bound to a completely new and monolitic interface.

So?  It's stil additional, new code for an approach which will have to
be superceded real soon.  That's just pure overhead to me.
-
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/