Messages in this thread Patch in this message | | | Subject | Re: Softirq priority inversion from "softirq: reduce latencies" | From | Eric Dumazet <> | Date | Mon, 29 Feb 2016 08:21:54 -0800 |
| |
On lun., 2016-02-29 at 07:54 -0800, Peter Hurley wrote:
> The current kernel is HZ=250 but this would occur on HZ=1000 as well.
Right. But the problem with HZ=100 and HZ=250 is that the detection can happens because jiffy granularity is too coarse, since
msecs_to_jiffies(2) -> 1
Following patch might reduce the probability, but wont really fix your problem.
Fact that ksoftirqd prio is not what you want is completely orthogonal.
diff --git a/kernel/softirq.c b/kernel/softirq.c index 479e443..f7cc594 100644 --- a/kernel/softirq.c +++ b/kernel/softirq.c @@ -180,7 +180,7 @@ EXPORT_SYMBOL(__local_bh_enable_ip); /* * We restart softirq processing for at most MAX_SOFTIRQ_RESTART times, - * but break the loop if need_resched() is set or after 2 ms. + * but break the loop if need_resched() is set or after 2 ms/ticks. * The MAX_SOFTIRQ_TIME provides a nice upper bound in most cases, but in * certain cases, such as stop_machine(), jiffies may cease to * increment and so we need the MAX_SOFTIRQ_RESTART limit as @@ -191,7 +191,7 @@ EXPORT_SYMBOL(__local_bh_enable_ip); * we want to handle softirqs as soon as possible, but they * should not be able to lock up the box. */ -#define MAX_SOFTIRQ_TIME msecs_to_jiffies(2) +#define MAX_SOFTIRQ_TIME (1 + msecs_to_jiffies(2)) #define MAX_SOFTIRQ_RESTART 10 #ifdef CONFIG_TRACE_IRQFLAGS
| |