Re: [linux-next:master] [sched/fair] fb1050ac8e: netperf.Throughput_Mbps 14.6% regression

[Peter Zijlstra]

On Thu, Jul 30, 2026 at 02:14:21PM +0800, Oliver Sang wrote:
> hi, Peter Zijlstra,
> 
> we are currently piloting AI integrations to help enhance 0-Day's performance
> analysis and regression-detection capabilities. Since this is in an early trial
> phase, we want to ensure we build features that genuinely support your workflow.
> We would love to hear what you would like to see from AI-assisted reports, whether
> it's specific bottleneck explanations, a cleaner format, or filtering ideas.
> 
> Please share your thoughts and suggestions with us to help guide our development!

As with most AI output, I find it incredibly hard to read -- for some
reason my brain keeps wandering and then I have to restart and refocus.
I'm not entirely sure what causes this, but I know I'm not the only one
faced with this.

That said, I struggled through it, and while it goes a little off the
rails at times (eg. the callgraph stuff doesn't at all seem relevant
here), it seems to be mostly on point.

There are a few things that I find missing that might be possible:

 - determine the specific task that is now preempting less; I suspect it
   is ksoftirqd because network workload.

   I suspect it doesn't have the data to determine this, but it should
   probably ask for such data and or, if it has access to the guest
   running this, gather it itself.

 - a section on possible 'mitigations' for this regression given
   existing configuration options. It touched upon the new debugfs knob
   to revert to the old behaviour, but I suspect that setting a shorter
   slice on ksoftirq might also help.

   That is, something like so:

   ps -def | awk '/ksoftirqd/ { if ($0 !~ /awk/) print $2}' | while read pid;
   do
     chrt --pid -o -T $((`cat /sys/kernel/debug/sched/base_slice_ns`/10)) $pid;
   done

   or perhaps the opposite, giving the netperf thing a larger slice such
   that ksoftirq will more reaily preempt it.

   And then there is of course the option to renice things, the netperf
   cgroup could be given a smaller slice or ksoftirq a larger.

   (all operating under the assumption that it is indeed ksoftirq that
   is now ran less readily)
   

This is the only regression found so far for tip/sched/core?