From: Mike Blumenkrantz <mike@zentific.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2 epoll questions
Date: Tue, 30 Nov 2010 21:43:02 -0500 [thread overview]
Message-ID: <20101130214302.3e0ca37a@darc.ath.cx> (raw)
In-Reply-To: <1291100631.2725.39.camel@edumazet-laptop>
On Tue, 30 Nov 2010 08:03:51 +0100
Eric Dumazet <eric.dumazet@gmail.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.
prev parent reply other threads:[~2010-12-01 2:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-30 0:17 Mike Blumenkrantz
2010-11-30 7:03 ` Eric Dumazet
2010-12-01 2:43 ` Mike Blumenkrantz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101130214302.3e0ca37a@darc.ath.cx \
--to=mike@zentific.com \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome