Page MenuHomeFreeBSD

sched_4bsd: Remove obsolete SMP scaling for ticks per priority level
AcceptedPublic

Authored by olce on Wed, Jun 24, 6:37 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Jul 11, 1:03 AM
Unknown Object (File)
Thu, Jul 9, 1:01 AM
Unknown Object (File)
Tue, Jul 7, 7:21 AM
Unknown Object (File)
Mon, Jul 6, 4:16 PM
Unknown Object (File)
Sun, Jul 5, 5:15 PM
Unknown Object (File)
Sun, Jul 5, 5:12 PM
Unknown Object (File)
Sat, Jul 4, 6:43 AM
Unknown Object (File)
Sat, Jul 4, 6:40 AM
Subscribers

Details

Summary

The INVERSE_ESTCPU_WEIGHT scaling had been introduced by commit
b698380f33ef ("Quick fix for scaling of statclock ticks in the SMP
case. ...") to leave more discrimination room for multiple CPUs possibly
adding their ticks to the same 'struct ksegrp' (but also slightly
changing how CPU hogs are penalized).

Then, commit 8460a577a4b4 ("Make KSE a kernel option, ...") introduced
the current thread-based code, where tick accounting is only done on the
current thread, which renders this trick obsolete on !KSE.

Finally, when KSE was removed, the trick became generally obsolete.

The trick is actually even harmful because it changes the intended
behavior of priorizing more the CPUs that use the less ticks (and so,
impairs boosting "interactive" processes).

Remove it now. Clamping of 'ts_estcpu' and its relation to the
load-average-based decay may be re-examined later.

Fixes: 8460a577a4b4 ("Make KSE a kernel option, ...")
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 74209
Build 71092: arc lint + arc unit

Event Timeline

olce requested review of this revision.Wed, Jun 24, 6:37 PM

LGTM. I didn't know this was from KSE times, but yes, we should let it go now.

I'm not sure about the INVERSE_ESTCPU_WEIGHT 8 part. Maybe this was found with some repeated experiments, but it might not make sense anymore with modern workloads. I don't have time right now to find the optimal value, so let's revisit this later.

This revision is now accepted and ready to land.Thu, Jul 2, 10:35 PM