Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #85692 > unrolled thread

Bug#972709: Wishlist/RFC: Change to CONFIG_PREEMPT_NONE in linux-image-cloud-*

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#972709: Wishlist/RFC: Change to CONFIG_PREEMPT_NONE in linux-image-cloud-* Salvatore Bonaccorso <carnil@debian.org> - 2025-02-20 10:40 +0100

#85692 — Bug#972709: Wishlist/RFC: Change to CONFIG_PREEMPT_NONE in linux-image-cloud-*

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

[toc] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web