From: Jamie Lokier <jamie@shareable.org>
To: Lennert Buytenhek <buytenh@math.leidenuniv.nl>
Cc: Davide Libenzi <davidel@xmailserver.org>, linux-kernel@vger.kernel.org
Subject: Re: {sys_,/dev/}epoll waiting timeout
Date: Wed, 22 Jan 2003 08:03:22 +0000 [thread overview]
Message-ID: <20030122080322.GB3466@bjl1.asuk.net> (raw)
In-Reply-To: <20030122065502.GA23790@math.leidenuniv.nl>
Lennert Buytenhek wrote:
> Both /dev/epoll EP_POLL and sys_epoll_wait, when converting the passed
> timeout value in msec to jiffies, round down instead of up. This
> occasionally causes these functions to return without any active fd's
> before the given timeout period has passed.
So you would like it to round up the timeout like poll(), select(),
and io_getevents() do? Fair enough, for the sake of consistency!
sys_poll() says:
if (timeout) {
/* Careful about overflow in the intermediate values */
if ((unsigned long) timeout < MAX_SCHEDULE_TIMEOUT / HZ)
timeout = (unsigned long)(timeout*HZ+999)/1000+1;
else /* Negative or overflow */
timeout = MAX_SCHEDULE_TIMEOUT;
}
sys_io_getevents() does something more complicated in a function
called set_timeout(), but it essentially comes to the same thing. It
takes a value in nanseconds (which I prefer, btw, for future usefulness).
There is also a nasty overflow in ep_poll(). If HZ == 1000 and
you ask to wait for > approx. 2000 seconds (not unreasonable, say if
epoll is running an ftp server and the client timeout is set to 1
hour), then ep_poll gets the calculation wrong.
I suggest that this line in eventpoll.c:
jtimeout = timeout == -1 ? MAX_SCHEDULE_TIMEOUT: (timeout * HZ) / 1000;
be changed to this:
jtimeout = 0;
if (timeout) {
/* Careful about overflow in the intermediate values */
if ((unsigned long) timeout < MAX_SCHEDULE_TIMEOUT / HZ)
jtimeout = (unsigned long)(timeout*HZ+999)/1000+1;
else /* Negative or overflow */
jtimeout = MAX_SCHEDULE_TIMEOUT;
}
And that the prototypes for ep_poll() and sys_epoll_wait() be changed
to take a "long timeout" instead of an "int", just like sys_poll().
> Effectively causing busy-wait loops of on average half a jiffy.
Sometimes busy waiting is the right thing to do. With HZ == 100,
anything involving video animation needs to busy wait after select()
or equivalent, otherwise there is too much display jitter.
But all that sort of code needs to know how much select() et al. tend
to overrun by anyway, so they can just do the same if using epoll.
-- Jamie
ps. sys_* system-call functions should never return "int". They
should always return "long" or a pointer - even if the user-space
equivalent returns "int". Take a look at sys_open() for an example.
Technical requirement of the system call return path on 64-bit targets.
next prev parent reply other threads:[~2003-01-22 7:54 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-22 6:55 Lennert Buytenhek
2003-01-22 8:03 ` Jamie Lokier [this message]
2003-01-22 12:46 ` Ed Tomlinson
2003-01-22 13:20 ` Jamie Lokier
2003-01-22 19:14 ` Randy.Dunlap
2003-01-22 19:34 ` Jamie Lokier
2003-01-22 19:32 ` Randy.Dunlap
2003-01-23 14:07 ` Davide Libenzi
2003-01-23 15:43 ` Jamie Lokier
2003-01-23 17:27 ` Mark Mielke
2003-01-23 18:28 ` Jamie Lokier
2003-01-23 20:40 ` Mark Mielke
2003-01-23 22:18 ` Jamie Lokier
2003-01-24 14:41 ` Andreas Schwab
2003-01-25 1:08 ` Davide Libenzi
2003-01-27 21:27 ` bug in select() (was Re: {sys_,/dev/}epoll waiting timeout) Bill Rugolsky Jr.
2003-01-27 22:52 ` Davide Libenzi
2003-01-28 9:45 ` Jamie Lokier
2003-01-28 10:52 ` Mark Mielke
2003-01-28 21:39 ` Jamie Lokier
2003-01-28 22:15 ` Davide Libenzi
2003-01-28 19:42 ` {sys_,/dev/}epoll waiting timeout Randy.Dunlap
2003-01-28 21:36 ` Jamie Lokier
2003-01-28 21:44 ` David Mosberger
[not found] <20030122080322.GB3466@bjl1.asuk.net.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.33L2.0301281139570.30636-100000@dragon.pdx.osdl.net.suse.lists.linux.kernel>
[not found] ` <20030128213621.GA29036@bjl1.asuk.net.suse.lists.linux.kernel>
2003-01-28 21:55 ` Andi Kleen
2003-01-28 22:24 ` Davide Libenzi
2003-01-28 22:39 ` Andi Kleen
2003-01-28 23:00 ` Davide Libenzi
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=20030122080322.GB3466@bjl1.asuk.net \
--to=jamie@shareable.org \
--cc=buytenh@math.leidenuniv.nl \
--cc=davidel@xmailserver.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®