Re: poll() in 2.6 and beyond

From: Dave Dillow (dave_at_thedillows.org)
Date: 03/03/04

  • Next message: Paul Armor: "(no subject)" 
    To: root@chaos.analogic.com
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/
  • Next message: Paul Armor: "(no subject)"

    Relevant Pages

    • Re: Are a set and trips different ?
      ... set involves a pair in the hole. ... I can't believe you started a poll to "prove your point" LOL, ... Board" and they just repeat it ad nauseum. ...
      (rec.gambling.poker)
    • Re: Looking for Linux equivalent of IO Completion Ports...
      ... > You snipped my justification, which I will repeat: ... > In fact, under most realistic conditions, 'poll' gets more efficient as ... > the number of connections goes up because the greater work to be done after ...
      (comp.os.linux.development.apps)
    • Re: Heidis Participation in Sci.lang...
      ... The problem with you creating the poll is the same as the problem with ... And I want to repeat: the problem with you is not the low level of ... intellectual curiosity that made learning possible. ...
      (sci.lang)
    • Re: Race between "mount" uevent and /proc/mounts?
      ... We could try to emit busy/free events from bd_claimand ... (even opens with O_EXCL), but not by things like volume_id. ... will call poll() on /proc/mounts. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: So, Poll is not scalable... what to do?
      ... Willy Tarreau wrote: ... I don't think that poll performance will be your worst ... 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/ ...
      (Linux-Kernel)