On Fri, 2016-06-10 at 17:30 +0200, Sebastian Andrzej Siewior wrote:
> * Steven Rostedt | 2016-05-26 19:56:41 [-0400]:
>
> >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.
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
