linux-kernel - Re: 2 epoll questions

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]

Date:	Tue, 30 Nov 2010 21:43:02 -0500
From:	Mike Blumenkrantz <mike@...tific.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: 2 epoll questions

On Tue, 30 Nov 2010 08:03:51 +0100
Eric Dumazet <eric.dumazet@...il.com> wrote:

> Le lundi 29 novembre 2010 à 19:17 -0500, Mike Blumenkrantz a écrit :
> > Hi,
> > 
> > I am not subscribed to the list yet, and I would appreciate it if all
> > replies could be CCed to me :).
> > 
> > I have two questions regarding epoll.  The epoll code that I am using can
> > all be found in the file here for those interested:
> > https://svn.enlightenment.org/svn/e/trunk/ecore/src/lib/ecore/ecore_main.c
> > 
> > 1) Is there any known reason why adding fds to an epoll fd would begin to
> > slow down dramatically after ~6000 fds are added?  It is entirely possible
> > that the problem is not epoll at all, but I wanted to ask and see if there
> > was some O(n) code somewhere that was known.
> > 
> 
> No particular slowdown, I once used more than 1.5 million fds in epoll
> fd.
> 
> Of course, if you only add/remove fds as fast as possible, its going to
> be slower, since epoll fds are stored in a tree, and the time of
> insert/delete of one item depends on the tree depth. Maybe this is your
> case and your working set is larger than your cpu caches after ~6000
> fds ?
Upon hearing that you have successfully used 1.5 million fds, I began analyzing
the code further and discovered one remaining instance of O(n) code.  Upon
removal, execution proceeded as expected for O(1) during runtime.
> 
> 
> > 2) If a select on an epoll fd (not one inside the epoll, the actual epoll fd
> > itself) returns EBADF, is there a way to determine which fd is causing the
> > error and then remove it?  I am occasionally running into this issue, and it
> > seems to be caused by code which I do not necessarily control closing a fd
> > that is part of my epoll fd without my knowledge (meaning that the closed
> > fd is still in epoll).
> 
> Strange, I never got this EBADF error. On epoll_ctl() or epoll_wait() ?
> (I dont understand your "select on epoll fd"). epoll is meant to replace
> select()...
In some cases, you cannot use epoll_wait because you are using fds from other
libraries which you do not control (here we have integrated glib's main loop
into our own, and so are monitoring fds which we do not directly own).  In
these cases, you must use select instead.
> 
> When you close a file descriptor, its automatically removed from epoll
> as well.

-- 
Mike Blumenkrantz
Zentific: Our boolean values are huge.
--
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/