Hi, On Fri, 2018-01-19 at 16:46 +0100, Frederic Weisbecker wrote: > As per Linus suggestion, this take doesn't limit the number of occurences > per jiffy anymore but instead defers a vector to workqueues as soon as > it gets re-enqueued on IRQ tail. > > No tunable here, so testing should be easier. > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > softirq/thread-v3 > > HEAD: 6835e92cbd70ef4a056987d2e1ed383b294429d4
I tested this series in the UDP flood scenario, binding the user space process receiving the packets on the same CPU processing the related IRQ, and the tput sinks nearly to 0, like before Eric's patch. The perf tool says that almost all the softirq processing is done inside the workqueue, but the user space process is scheduled very rarely, while before this series, in this scenario, ksoftirqd and the user space process got a fair share of the CPU time. Cheers, Paolo