On Thu, 31 Aug 2017 18:23:49 +0200 Michal Kubecek <mkube...@suse.cz> wrote:
> If we go this way (which would IMHO require some benchmarks to make sure > it doesn't harm performance too much) we can drop the explicit checks > for zero thresholds which were added to work around the unreliability of > fast checks of percpu counters (or at least the second one was by commit > 30759219f562 ("net: disable fragment reassembly if high_thresh is zero"). After much considerations, together with Florian, I'm now instead looking at reverting the use of percpu_counter for this memory accounting use-case. The complexity and maintenance cost is not worth it. And I'm of-cause testing the perf effect, and currently I'm _not_ seeing any perf regression on my 10G + 100G testlab (although this is not a NUMA system, which were my original optimization case). -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer