poll_wait function - Linux

This is a discussion on poll_wait function - Linux ; Hi, I do not understand how the polling works for device drivers from the kernel perspective. Why does poll_wait take a queue parameter? (And as a queue head, not an queue entry?) How long does this queue get? And, where ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: poll_wait function

  1. poll_wait function

    Hi, I do not understand how the polling works for device drivers
    from the kernel perspective. Why does poll_wait take a queue
    parameter? (And as a queue head, not an queue entry?)
    How long does this queue get? And,
    where is there an explanation of the poll table?

    Thanks,
    -Mike

  2. Re: poll_wait function

    On May 8, 2:37*pm, Mike wrote:

    > Hi, I do not understand how the polling works for device drivers
    > from the kernel perspective. Why does poll_wait take a queue
    > parameter? (And as a queue head, not an queue entry?)


    So that you can wait for all of the events on the list.

    > How long does this queue get?


    It depends how many things the task is waiting for.

    Consider a call to 'poll' from user-space. In this case, assuming the
    task needs to wait, the kernel assembles a list of all of the events
    the task is waiting for, and then waits on the queue.

    > And,
    > where is there an explanation of the poll table?


    I think walking through do_poll (in fs/select.c) is the easiest way to
    understand it. The kernel first walks the list of entries, seeing if
    any are immediately ready. As it does so, it adds each event to the
    list of events to wait on. If there's a timeout, it then schedules
    itself to be woken up after the timeout, otherwise it returns.

    To see what happens if one of those events occurs, check out
    default_wake_function in kernel/sched.c which calls try_to_wake_up in
    that same file. This function is complex, but the basic idea is that
    it wakes up the process.

    I'm not sure I know exactly what you want more information on. Would
    it be helpful if I detailed the process by which a process calls
    'poll', blocks on a timeout, and then an event occurs? (The short
    answer is that every possible event has a wait queue, and the process
    adds itself to the appropriate wait queues, then goes to sleep. When
    the event occurs, the thing handling the event calls every wake
    handler on the queue for that event, waking up the process.)

    DS

  3. Re: poll_wait function

    Hi David,

    Thanks for your help, but I am not yet understanding this.
    I have some follow-up questions.

    On May 9, 12:57*am, David Schwartz wrote:
    > On May 8, 2:37*pm, Mike wrote:
    >
    > > Hi, I do not understand how the polling works for device drivers
    > > from the kernel perspective. Why does poll_wait take a queue
    > > parameter? (And as a queue head, not an queue entry?)

    >
    > So that you can wait for all of the events on the list.
    >
    > > How long does this queue get?

    >
    > It depends how many things the task is waiting for.



    I would have guessed the answer is,
    'It depends on how many tasks are waiting for this thing'.
    When a driver module declares a wait queue head, is not the queue
    for holding many different tasks waiting for this device? Does a
    driver
    module have separate queues for reading, writing, and exceptions?


    > I'm not sure I know exactly what you want more information on. Would
    > it be helpful if I detailed the process by which a process calls
    > 'poll', blocks on a timeout, and then an event occurs?


    Yes.

    (The short
    > answer is that every possible event has a wait queue, and the process
    > adds itself to the appropriate wait queues,


    This is done by the call to poll_wait, right? Does that function
    dynamically
    allocate memory for a wait queue entry?

    Thanks,
    -Mike


  4. Re: poll_wait function

    On May 9, 2:43*pm, Mike wrote:

    > > > Hi, I do not understand how the polling works for device drivers
    > > > from the kernel perspective. Why does poll_wait take a queue
    > > > parameter? (And as a queue head, not an queue entry?)

    >
    > > So that you can wait for all of the events on the list.

    >
    > > > How long does this queue get?

    >
    > > It depends how many things the task is waiting for.

    >
    > I would have guessed the answer is,
    > 'It depends on how many tasks are waiting for this thing'.
    > When a driver module declares a wait queue head, is not the queue
    > for holding many different tasks waiting for this device?


    You need both. When a task wakes up, you need to remove it from all
    the wait queues it is on. You can't search every single queue, so as a
    result, you also need a list of all the wait queues a task is on.

    > Does a
    > driver
    > module have separate queues for reading, writing, and exceptions?


    There are two ways to do this. You can have a separate queue for each
    event type or you can have a single queue that has a mask for which
    events will trigger a wakeup. I believe Linux uses the latter
    approach, but right now I'm at a machine that I can't easily confirm
    from.

    > > (The short
    > > answer is that every possible event has a wait queue, and the process
    > > adds itself to the appropriate wait queues,


    > This is done by the call to poll_wait, right? Does that function
    > dynamically
    > allocate memory for a wait queue entry?


    It may or may not be allocated already at that point. In the case of
    the actual 'poll' system call, poll_wait will reduce to __pollwait,
    which calls poll_get_entry. That will allocate space (using
    __get_free_page) if it hasn't already been allocated.

    Unfortunately, the card is very hard to read and follow due to both
    optimization and the fact that it is "fake object-oriented".

    DS

  5. Re: poll_wait function

    Let me ask this: When a module calls schedule(), obviously
    the return address is stored on the kernel stack for the
    current process. Is the stack pointer then, inside the
    schedule() function, the kernel stack for the "init" process,
    or some global stack?

    Thanks,
    -Mike

  6. Re: poll_wait function

    On May 10, 10:09*am, Mike wrote:

    > Let me ask this: When a module calls schedule(), obviously
    > the return address is stored on the kernel stack for the
    > current process. Is the stack pointer then, inside the
    > schedule() function, the kernel stack for the "init" process,
    > or some global stack?


    Every process has its own kernel stack. When a module calls
    'schedule', 'schedule' runs on the kernel stack of that process. If it
    winds up switching to another process, that other process (and its
    kernel stack) take over where they left off. Strange as it seems,
    every process that's blocked in the kernel is blocked on its own
    kernel stack, ready to resume execution by switching to that stack.

    DS

+ Reply to Thread