Thread (16 messages) 16 messages, 5 authors, 2016-09-03

Re: [PATCH][RT] netpoll: Always take poll_lock when doing polling

From: Eric Dumazet <hidden>
Date: 2016-06-10 16:29:03
Also in: lkml, netdev

On Fri, 2016-06-10 at 17:30 +0200, Sebastian Andrzej Siewior wrote:
* Steven Rostedt | 2016-05-26 19:56:41 [-0400]:
quoted
For example:

  <interrupt thread (as all interrupts on RT are threaded>

  napi_schedule_prep()
       test_and_set_bit(NAPI_STATE_SCHED, &n->state)

  <preempted by higher prio task that runs softirqs in its context>

  sk_busy_loop()

     do {
          rc = busy_poll()
              ret = napi_schedule_prep()
                   return !test_and_set_bit(NAPI_STATE_SCHED, &n->state)
                    <returns zero because NAPI_STATE_SCHED is set>
              if (!ret) return 0
          <rc is zero>
     } while (...) /* for ever */
No, I don't see the busyloop. while() is here:
|    while (!nonblock && skb_queue_empty(&sk->sk_receive_queue) &&
|                  !need_resched() && !busy_loop_timeout(end_time));

and this seems to be the case since v3.11 where it was introduced (but
now it moved to dev.c). So even if there is no busy_poll() and
napi_schedule_prep() returns 0 our cycles here are limited by
busy_loop_timeout().
Well, before linux-4.5 and commit 2a028ecb76497d ("net: allow BH
servicing in sk_busy_loop()") , sk_busy_loop() was completely blocking
BH.

Not sure it matters in your case.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help