RE: [PATCH 0/4] sched: Various reweight_entity() fixes

[Doug Smythies]

On 2026.02.13 02:50 Peter Zijlstra wrote:
> On Fri, Feb 13, 2026 at 07:44:24AM +0100, Peter Zijlstra wrote:
>> As to wrapper, I just went through math64.h and it appears we have
>> div64_long() that might just DTRT, but I really need to go wake up
>> first.
>> 
>> And as you noted, the current branch doesn't boot :/ No idea what I
>> messed up last night, but I did push without test building. I only
>> folded those two division fixed and figured what could possibly go wrong
>> :-)
>
> It's now got div64_long() throughout.
>
> I've build and booted each commit in a vm; build and booted the combined
> stack on 2 different physical machines and re-ran the various
> benchmarks.
>
> Works-for-me.

Works for me also.

Note: I am calling this "V5" (version 5).

But: please consider if there is an issue or not with test 3 below,
mainly detailed in the attached graphs.

Testing order was from least to most time consuming.

1.) Phoronix version of hackbench, same settings as my previous reports:
Run 1 of 2, 10 tests per run: Average: 22.685 Seconds; Deviation: 0.27%
Run 2 of 2, 10 tests per run: Average: 22.775 Seconds; Deviation: 0.24%
Conclusion: Pass.

2.) a ridiculous number of threads test. Each thread mostly sleeps.
Note 1: Not previously mentioned, but I have been doing this test for years, just to see if it works.
Note 2: Other default limits need to be increased for this test. Example:
	doug@s19:~$ cat /sys/fs/cgroup/user.slice/user-1000.slice/pids.max
	84080
	doug@s19:~$ echo 400000 | sudo tee /sys/fs/cgroup/user.slice/user-1000.slice/pids.max
	400000
	doug@s19:~$ cat /sys/fs/cgroup/user.slice/user-1000.slice/pids.max
	400000
Note 3: The maximum number of threads attempted is determined by the amount of system memory.
	In my case the memory limit is around 220,000 threads.
Note 4: There never was an issue with this test, even for previous versions of this patch set.
Details:
	doug@s19:~$ cat /sys/fs/cgroup/user.slice/user-1000.slice/pids.current
	220015
	doug@s19:~$ uptime
 	08:22:23 up 26 min,  4 users,  load average: 0.99, 15.19, 36.38
	doug@s19:~$ free -m
		total	used	free	shared	buff/cache	available
	Mem:	31928	28767	2985	5	568		3161
	Swap:	  8191	         0	8191
Conclusion: Pass.

3.) a ridiculous load. Each thread is 100% load, no sleep. 20,000 X yes:
Conclusion: Pass?
Observation: The spin out rate of tasks is "clunky" not smooth. It used to be smooth.
	A couple of graphs are attached. Note that actual sample times are now used,
	after a nominal sleep of 2 seconds between samples. Sometimes the actual
	gap is over 1 minute. It takes considerably longer, 2,200 seconds verses
	1,309 seconds to spin out the 20,000 takes for V5 verses kernel 6.19-rc8.

4.) Back to the original complaint from a year ago [1]: With a ridiculous load, is there a big delay for SSH login?
Note 1: I don't care either way, I just tried it.
Details:	SSH login times were all between 6 and 8 seconds.
Conclusion: Pass.

5.) Under 100.0% load (in my case 12 X yes) are there unreasonably long times between samples for turbostat?
Histograms (3 hours and 39 minutes test run time):

Peter's cool way:
$ gawk '/^usec/ {next} { if (T) { d=$2-T; bucket[int(d*1000)]++; } T=$2 } END { for (i in bucket) { printf "%0.3f: %d\n", i/1000,
bucket[i] }}' < /dev/shm/turbo.log
1.000: 6870
1.001: 5647
1.002: 25
1.003: 6
1.005: 1

My old way: Not done.

[1] https://lore.kernel.org/lkml/002401dbb6bd$4527ec00$cf77c400$@telus.net/

Attachment: pz-task-sample-gaps.png
Description: PNG image

Attachment: pz-task-rate.png
Description: PNG image