Re: poll() in 2.6 and beyond

[Dave Dillow <dave@thedillows.org>]

On Wed, 2004-03-03 at 13:23, Richard B. Johnson wrote:
> The very great problems that exist with poll on linux-2.6.0
> are being quashed by those who just like to argue.

No, the argument has always been that your understanding of poll()'s
internals is not entirely correct. We have simply asked you to post code
that shows poll()'s problems, which you have finally provided. Sort of.

>  Therefore,
> I wrote some code that emulates the environment in which I
> discovered the poll failure. Experts can decide whatever they
> want about the inner workings of poll(). I supposed that if
> `ps` showed that a task was sleeping in poll() then it must
> be sleeping in poll(). 

This we all agree on -- poll() sleeps. Duh. No argument there.
poll_wait() doesn't and never has, which was your original assertion.

But on to the code!

> So, even it that's wrong, here is
> irrefutable proof that there is a problem with polling events
> getting lost on 2.6.0.

Ahem, no, not so much. What you have here is proof that your user
program is not getting control again withing 0.488ms of the interrupt
happening. That does not mean poll() is loosing events.

You are definately seeing some significant latency -- 50 lost increments
is ~25ms.

What else is running when you perform this test? Can you repeat with a
more recent kernel? Can you repeat in single user mode, with it being
the only process present? With as few extra modules loaded as possible?

I still think your problem is not poll() -- if there were problems
there, bug reports would be coming out of the woodwork.
-- 
Dave Dillow <dave@thedillows.org>