Hi, On Sun, Nov 22, 2020 at 05:49:22PM -0800, Noah Meyerhans wrote: > On Sun, Nov 22, 2020 at 03:53:32PM -0800, Flavio Veloso Soares wrote: > > Unfortunately, I couldn't find many comprehensive benchmarks of kernel > > CONFIG_PREEMPT* options. The one at > > > > [1]https://www.codeblueprint.co.uk/2019/12/23/linux-preemption-latency-throughput.html > > seems to be very thorough, > > > > [...] > > > > Not particularly. I'm used to latency benchmarks showing e.g. average, > > 90th percentile, 99th percentile, as well as worst. > > I don't think Ben was talking about specific benchmarks. The web page > you cites lacks basic measurements one would expect to see from *any* > meaningful performance benchmark. Comparing maximum latency is fine, > but it's not really relevant by itself. If a configuration change > improves the worst case (100th percentile) but negatively impacts the > 50th percentile, is that a change worth making? Maybe. But without > having that data at all, the benchmark really isn't worth much at all. > > It's totally reasonable for us to consider making this change, but we > should have comprehensive data about the impact of doing so. What > impact does the change have on different classes of workloads? e.g. > high tps, CPU-bound, IO-bound, etc. It's entirely possible that the > proposed change improves performance under certain workloads, but > negatively impacts others. Without knowing the impact in more in more > detail, which would allow us to evaluate the tradeoffs, I don't think > there's a compelling reason to make a change.
I think with setting CONFIG_PREEMPT_LAZY since 6.13.2-1~exp1 we can close this wishlist bug with that version? Regards, Salvatore
