Results on "x86 Gentoo 3.x" buildbot:

[136/389] test_asyncio
WARNING: selector.select(timeout=0.09997069113887846470) took dt=0.09961039200425148010 sec (dt-timeout=-0.00036029913462698460)
WARNING: dt+0.00100000000000000002 > timeout? True
WARNING: selector.select(timeout=0.09995610709302127361) took dt=0.09992253710515797138 sec (dt-timeout=-0.00003356998786330223)
WARNING: dt+0.00100000000000000002 > timeout? True
WARNING: selector.select(timeout=0.00994763919152319431) took dt=0.00972709804773330688 sec (dt-timeout=-0.00022054114378988743)
WARNING: dt+0.00100000000000000002 > timeout? True

Ok, it looks better: waiting 99.9 ms took 99.6 ms and 99.9 ms, and waiting 9.9 ms took 9.7 ms. So as I said, the granularity (of 1 ms) is still needed in asyncio (dt < timeout is sometimes False, but dt+granulary >= timeout is always True).

We could round the timeout by adding 2 ms in epoll.poll(), but it would be inefficient: it reduces the accurary of 1 ms, whereas the change would only be needed by asyncio. IMO the granularity rounding is better because it uses also the resolution of the clock, which matters a lot on Windows whereas time.monotonic() has a resolution of 15.6 ms.

There are same results on "x86 Gentoo Non-Debug 3.x" and "x86 Ubuntu Shared 3.x" buildbots.

--

In test_signal_handling_args, dt+granularity > timeout is still True, because the selector was interrupted by a signal. For this case, loop_run_once.patch avoids a second call to _run_once(), but in fact it doesn't optimize anything (calling _run_once() again is just the same). Calling _run_once() again if selector was interrupted is just fine IMO. Example of interrupted selector:

WARNING: selector.select(timeout=0.49998722597956657410) took dt=0.10003586183302104473 sec (dt-timeout=-0.39995136414654552937)
WARNING: dt+0.00100000000000000002 > timeout? False

--

For time handling on Linux, see also:
http://www.python.org/dev/peps/pep-0418/#linux-clocksource