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

On Thu, Jul 30, 2026 at 04:32:39PM +0200, Peter Zijlstra wrote:
> 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.

'weight' not 'slice' here.

> 
>    (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?