Messages in this thread | | | Subject | Re: poll() in 2.6 and beyond | From | Dave Dillow <> | Date | Wed, 03 Mar 2004 14:29:19 -0500 |
| |
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>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |