Re: [RFC PATCH 0/6] sched/fair: Introduce the SMT_BUDDY_ASSIST feature

[Li kunyu]

Hi Kayra,

On 2026/10/21 20:44, Kayra Cizmeci wrote:
> On Tue, Oct 20, 2026 at 04:37:40PM +0800, Li kunyu wrote:
> 
>> Several benchmarks show performance regressions:
>>
>> 1. tbench 32      8325.17    6772.693     -18.65%(degeneration):
>> Each tbench sample was run three times. Initially, some measurement
>> error was observed. Moreover, this patch series essentially utilized all
>> idle CPUs, whereas without the feature enabled, 5% to 10% of idle CPUs may
>> remain idle. This led to more CPUs experiencing cache interference and
>> other effects. The results are benign and within an acceptable range.
> According to what the results are 'acceptable'? If there were some error
> why even talk about them?

The main point here is to describe the temporary performance degradation
observed in tbench 32 test case.

When multiple CPUs each have bursty tasks (by default, at least four tasks per
CPU), moving pending or newly created tasks to an idle CPU incurs temporary
extra overhead, such as TLB refresh and page copying/migration. Once the tasks
settle, migration succeeds and they start running performance returns to a
higher level. For example:

1. If the CPU originally selected for the task has good LLC (L3) memory
bandwidth, choosing an idle CPU in a different LLC scheduling domain briefly
incurs this overhead; however, after recovery, memory access latency returns to
normal and throughput returns to its normal value.

2. If the originally selected CPU's LLC (L3) memory bandwidth is already a
bottleneck, choosing an idle CPU in a different LLC scheduling domain can reduce
memory access latency (the migration overhead is even lower) while also
improving throughput for NVMe and other storage devices.

In this test case, we quickly utilized the idle CPUs. Once those idle CPUs have
tasks, they enter the normal load-balancing process, which helps achieve an even
CPU load distribution quickly. Therefore, the temporary performance degradation
is acceptable.

In addition, in the patch I am currently optimizing for my own tests, changing
rq->nr_running to rq->cfs.h_nr_runnable (so that sleeping tasks are excluded
from the count) reduced the degradation from -18.65% to -8.55% and produced
significant improvements in stream-10 and stream-100.


-- 
thanks,
kunyu