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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7BA85550-4E33-4C5B-B855-716512D2105E@oracle.com>
Date: Tue, 10 Jun 2025 16:31:05 +0000
From: Prakash Sangappa <prakash.sangappa@...cle.com>
To: Steven Rostedt <rostedt@...dmis.org>
CC: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "mathieu.desnoyers@...icios.com" <mathieu.desnoyers@...icios.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "kprateek.nayak@....com"
	<kprateek.nayak@....com>,
        "vineethr@...ux.ibm.com" <vineethr@...ux.ibm.com>
Subject: Re: [PATCH V5 1/6] Sched: Scheduler time slice extension



> On Jun 9, 2025, at 2:33 PM, Steven Rostedt <rostedt@...dmis.org> 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