Re: [PATCH V5 1/6] Sched: Scheduler time slice extension

From: Prakash Sangappa
Date: Tue Jun 10 2025 - 12:31:42 EST




> On Jun 9, 2025, at 2:33 PM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
>
> Now I put the machine under load.
>
> In one window I ran:
>
> $ cd linux.git
> $ make j=20
>
> [ This is just a 8 core machine. I just noticed that I have isolcpus=3 so
> only 7 are running ]
>
> And in another window I ran:
>
> $ while :; ./hackbench 50; done
>
> This made the system have:
>
> ~# cyclictest --smp -p95 -m -s --system -l 100000 -b 1000
> # /dev/cpu_dma_latency set to 0us
> policy: fifo: loadavg: 38.84 19.89 8.05 29/2609 80387
>
> T: 0 (71748) P:95 I:1000 C: 23386 Min: 5 Act: 10 Avg: 9 Max: 30
> T: 1 (71749) P:95 I:1500 C: 15635 Min: 5 Act: 7 Avg: 9 Max: 24
> T: 2 (71750) P:95 I:2000 C: 11735 Min: 6 Act: 11 Avg: 10 Max: 27
> T: 3 (71751) P:95 I:2500 C: 9388 Min: 6 Act: 9 Avg: 10 Max: 24
> T: 4 (71753) P:95 I:3000 C: 7823 Min: 6 Act: 10 Avg: 10 Max: 24
> T: 5 (71755) P:95 I:3500 C: 6699 Min: 6 Act: 10 Avg: 10 Max: 23
> T: 6 (71756) P:95 I:4000 C: 5865 Min: 6 Act: 10 Avg: 9 Max: 23
>
> Then running my extend-sched with 5us delay, it jumped up slightly.
>
> T: 0 (104507) P:95 I:1000 C: 69385 Min: 4 Act: 10 Avg: 8 Max: 34
> T: 1 (104509) P:95 I:1500 C: 46378 Min: 4 Act: 14 Avg: 9 Max: 29
> T: 2 (104510) P:95 I:2000 C: 34829 Min: 5 Act: 13 Avg: 9 Max: 27
> T: 3 (104511) P:95 I:2500 C: 27885 Min: 5 Act: 11 Avg: 9 Max: 28
> T: 4 (104512) P:95 I:3000 C: 23246 Min: 5 Act: 12 Avg: 9 Max: 29
> T: 5 (104514) P:95 I:3500 C: 19931 Min: 5 Act: 11 Avg: 9 Max: 32
> T: 6 (104518) P:95 I:4000 C: 17446 Min: 5 Act: 11 Avg: 9 Max: 24
>
> This is more in the noise but still sightly noticeable. I still argue that
> this extends any worst case scenario with the delay, as if the path that
> causes the worst case scenario happens when the extended slice happens,
> they are combined. Which is the definition of worst case scenario.

Ok, adding load also seems to increase the max latency.

It is up to Peter to decide if scheduler time extension should be restricted to non RT threads.

We could add a new CONFIG which can be used to disable this
feature for PREEMPT_RT, if that is what you are suggesting.

Will setting the tunable 'sched_preempt_delay_us ‘ to 0, which would disable the feature
not suffice?.

-Prakash

> -- Steve