All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Varsanyi <e0206@foo21.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: Eric Varsanyi <e0206@foo21.com>,
	linux-kernel@vger.kernel.org, davidel@xmailserver.org
Subject: Re: [Patch][RFC] epoll and half closed TCP connections
Date: Sat, 12 Jul 2003 15:51:14 -0500	[thread overview]
Message-ID: <20030712205114.GC15643@srv.foo21.com> (raw)
In-Reply-To: <20030712194432.GE10450@mail.jlokier.co.uk>

> > In a level triggered world this all just works because the read ready
> > indication is driven back to the app as long as the socket state is half
> > closed. The event driven epoll mechanism folds these two indications
> > together and thus loses one 'edge'.
> 
> Well then, use epoll's level-triggered mode.  It's quite easy - it's
> the default now. :)

The problem with all the level triggered schemes (poll, select, epoll w/o
EPOLLET) is that they call every driver and poll status for every call into
the kernel. This appeared to be killing my app's performance and I verified
by writing some simple micro benchmarks.

I can post the details and code if anyone is interested, the summary is
that on 1 idle FD poll, select, epoll all take about 900ns on a 2.8G P4
(around the overhead of any syscall). With 10 idle FD's (pipes or sockets)
the overhead is around 2.5uSec, at 400fd's (a light load for this app)
we're up to 80uSec per call and the app is spending almost 100% of one
CPU in system mode with even a light tickling of I/O activity on a few
of the fd's.

As we start to scale up to production sized fd sets it gets crazy: around
8000 completely idle fd's the cost is 4ms per syscall. At this point
even a high real load (which gathers lots of I/O per call) doesn't cover the
now very high latency for each trip into the kernel to gather more work.

What was interesting is the response time was non-linear up to around 400-500
fd's, then went steep and linear after that, so you pay much more (maybe due
to some cache effects, I didn't pursue) for each connecting client in a light
load environment.

This is not web traffic, the clients typically connect and sit mostly idle.

> If there's an EOF condition pending after you called read(), and then
> you call epoll_wait(), you _should_ see another EPOLLIN condition
> immediately.
> 
> If you aren't seeing epoll_wait() return with EPOLLIN when there's an
> EOF pending, *and* you haven't set EPOLLET in the event flags, that's
> a bug in epoll.  Is that what you're seeing?

No, I am not asserting there is a problem with epoll in level triggered
mode (I've only used poll and select in level triggered mode, so I can't
say for sure it works either).

-Eric Varsanyi

  reply	other threads:[~2003-07-12 20:36 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-12 18:16 [Patch][RFC] epoll and half closed TCP connections Eric Varsanyi
2003-07-12 19:44 ` Jamie Lokier
2003-07-12 20:51   ` Eric Varsanyi [this message]
2003-07-12 20:48     ` Davide Libenzi
2003-07-12 21:19       ` Eric Varsanyi
2003-07-12 21:20         ` Davide Libenzi
2003-07-12 21:41         ` Davide Libenzi
2003-07-12 23:11           ` Eric Varsanyi
2003-07-12 23:55             ` Davide Libenzi
2003-07-13  1:05               ` Eric Varsanyi
2003-07-13 20:32       ` David Schwartz
2003-07-13 21:10         ` Jamie Lokier
2003-07-13 23:05           ` David Schwartz
2003-07-13 23:09             ` Davide Libenzi
2003-07-14  8:14               ` Alan Cox
2003-07-14 15:03                 ` Davide Libenzi
2003-07-14  1:27             ` Jamie Lokier
2003-07-13 21:14         ` Davide Libenzi
2003-07-13 23:05           ` David Schwartz
2003-07-13 23:11             ` Davide Libenzi
2003-07-13 23:52             ` Entrope
2003-07-14  6:14               ` David Schwartz
2003-07-14  7:20                 ` Jamie Lokier
2003-07-14  1:51             ` Jamie Lokier
2003-07-14  6:14               ` David Schwartz
2003-07-15 20:27             ` James Antill
2003-07-16  1:46               ` David Schwartz
2003-07-16  2:09                 ` James Antill
2003-07-13 13:12     ` Jamie Lokier
2003-07-13 16:55       ` Davide Libenzi
2003-07-12 20:01 ` Davide Libenzi
2003-07-13  5:24   ` David S. Miller
2003-07-13 14:07     ` Jamie Lokier
2003-07-13 17:00       ` Davide Libenzi
2003-07-13 19:15         ` Jamie Lokier
2003-07-13 23:03           ` Davide Libenzi
2003-07-14  1:41             ` Jamie Lokier
2003-07-14  2:24               ` POLLRDONCE optimisation for epoll users (was: epoll and half closed TCP connections) Jamie Lokier
2003-07-14  2:37                 ` Davide Libenzi
2003-07-14  2:43                   ` Davide Libenzi
2003-07-14  2:56                   ` Jamie Lokier
2003-07-14  3:02                     ` Davide Libenzi
2003-07-14  3:16                       ` Jamie Lokier
2003-07-14  3:21                         ` Davide Libenzi
2003-07-14  3:42                           ` Jamie Lokier
2003-07-14  4:00                             ` Davide Libenzi
2003-07-14  5:51                               ` Jamie Lokier
2003-07-14  6:24                                 ` Davide Libenzi
2003-07-14  6:57                                   ` Jamie Lokier
2003-07-14  3:12                     ` Jamie Lokier
2003-07-14  3:17                       ` Davide Libenzi
2003-07-14  3:35                         ` Jamie Lokier
2003-07-14  3:04                   ` Jamie Lokier
2003-07-14  3:12                     ` Davide Libenzi
2003-07-14  3:27                       ` Jamie Lokier
2003-07-14 17:09     ` [Patch][RFC] epoll and half closed TCP connections kuznet
2003-07-14 17:09       ` Davide Libenzi
2003-07-14 21:45       ` Jamie Lokier

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=20030712205114.GC15643@srv.foo21.com \
    --to=e0206@foo21.com \
    --cc=davidel@xmailserver.org \
    --cc=jamie@shareable.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.