Messages in this thread | | | Subject | Re: Softirq priority inversion from "softirq: reduce latencies" | From | Peter Hurley <> | Date | Mon, 29 Feb 2016 10:53:25 -0800 |
| |
On 02/29/2016 10:24 AM, Eric Dumazet wrote: > On lun., 2016-02-29 at 10:05 -0800, Peter Hurley wrote: > >> While I appreciate the attempt, that's not the problem. >> >> Just to be clear >> >> if (time_before(jiffies, end) && !need_resched() && >> --max_restart) >> goto restart; >> >> aborts softirq *even if 0ns have elapsed*, if NET_RX has woken a process. > > > Sure, now remove the 1st and 2nd condition.
Well just removing the 2nd condition has everything working fine, because that fixes the priority inversion.
> You would still 'abort' (ie wakeup ksoftirqd really) when --max_restart > becomes 0
Sure. Which would mean there's contended heavy i/o load so the driver has to fallback to non-DMA. That's an acceptable outcome.
> So, instead of some subtle load dependent bug, you know have a reliable > trigger.
There's no "subtle load dependent bug" here.
The driver has a fallback mode of operation that it relies on without DMA. Of course, as I already wrote, this has consequences.
If system resources are _actually contended_, then naturally, fighting for cpu and i/o time is fine, and I'm happy to do that in ksoftirqd.
However, when system resources are _not_ contended, it makes no sense to be forced to revert to ksoftirqd resolution, which is strictly intended as fallback.
Or flipping your argument on its head, why not just _always_ execute softirq in ksoftirqd?
| |