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

[Doug Smythies]

On 2026.02.13 22:31 Doug Smythies wrote:
> 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.

... snip ...

> 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.

Just a follow up:

The above reported concern with this test never had anything to do with this
patch series. It had everything to do with commit 7dadeaa6e851:

	sched: Further restrict the preemption modes

and my use of the Ubuntu kernel configuration. In the header of the commit
it says:

	While Lazy has been the recommended setting for a while,
	not all distributions have managed to make the switch yet.
	Force things along.

The kernel configuration was automatically modified eliminating 
PREEMPT_VOLUNTARY and leaving PREEMPT_LAZY disabled.
Once I set PREEMPT_LAZY the above noted concern was gone
(although I am still testing).

References:
https://lore.kernel.org/all/20251219101502.GB1132199@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/