From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: Bug: epoll_wait timeout is shorter than requested
Date: Mon, 17 Jan 2005 11:48:21 +0000
Message-ID: <20050117114821.GB20152@mail.shareable.org>
References: <87651wl32d.fsf@qrnik.zagroda>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: linux-fsdevel@vger.kernel.org
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mail.shareable.org ([81.29.64.88]:22197 "EHLO
	mail.shareable.org") by vger.kernel.org with ESMTP id S262775AbVAQLs0
	(ORCPT <rfc822;linux-fsdevel@vger.kernel.org>);
	Mon, 17 Jan 2005 06:48:26 -0500
To: "Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl>
Content-Disposition: inline
In-Reply-To: <87651wl32d.fsf@qrnik.zagroda>
Sender: linux-fsdevel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

Marcin 'Qrczak' Kowalczyk wrote:
> A program to exhibit the bug:

The epoll argument rounds like select(), not like poll().
It was done deliberately.

The epoll_wait() behaviour is deliberate, so that it is possible to
wait repeatedly for short time intervals of 1 timer tick.

> It should wait one second (at least). Example output on Linux-2.6.10:
> start: 1105958820.439410
> stop:  1105958821.438636
> 
> With poll used instead of epoll the timeout is OK:
> start: 1105958827.975209
> stop:  1105958828.975944
> 
> Is this list a good place to report this?

For example, on a system with a 100 Hz timer tick, if you want to write
a program which actually times out on each tick, you can write:

    select (nfs, rfds, wfds, efds, { 0, 10000 });
or
    epoll_wait (epfd, events, maxevents, 10);

That will pause until the next tick, allowing programs which need to
do some work smoothly at 100 Hz.

(If you simply want to track the kernel's tick whatever it is, you can
use {0,1} or 1 as the timeouts respectively).

With poll(), because of the way the timeout argument is rounded up by
a tick in the kernel, that's impossible:

    poll (fds, nfds, -1);   <- Waits for a long time.
    poll (fds, nfds, 0);    <- Does not wait at all.
    poll (fds, nfds, 1);    <- Waits for *second* tick after current one.

This means you can only service application events at 50 Hz on a
system where the kernel tick is 100 Hz, if using poll().

This limitation makes poll() unsuitable on Linux for programs which
need to service events at or close to the kernel's tick rate.

This isn't just a problem for programs doing low jitter work.  Many
programs call select/poll/epoll, and then call gettimeofday() after to
decide whether the next "timer" application event is ready to be
serviced, or whether to call select/poll/epoll again.  With the poll()
behaviour, if a previous poll() finished _just_ before the timer event
is ready, the application will call poll() again with timeout 1, and
then it will wait 10-20ms (on a 100 Hz kernel) instead of the far more
desirable 0-10ms.

For historical reasons, perhaps even accidentally, Linux' select()
call rounds the timeout differently and is suitable for this.  We
decided to not change poll() in case it breaks something, but to make
epoll copy the select() rounding because it's more useful.

Note that all programs which depend on select/poll/epoll waiting for
at least the specified time _should_ check the time afterwards anyway,
for example by calling gettimeofday() and waiting again if the desired
time isn't reached yet.

This is because all three calls will return earlier than expected
under some circumstances, i.e. EINTR.

-- Jamie