Page MenuHomeFreeBSD

ithreads: Support priority adjustment by schedulers.
ClosedPublic

Authored by jhb on Jun 28 2022, 10:31 PM.
Tags
None
Referenced Files
Unknown Object (File)
Oct 17 2024, 6:56 AM
Unknown Object (File)
Oct 2 2024, 7:29 PM
Unknown Object (File)
Sep 30 2024, 2:19 PM
Unknown Object (File)
Sep 9 2024, 4:16 PM
Unknown Object (File)
Sep 7 2024, 11:20 PM
Unknown Object (File)
Sep 6 2024, 2:57 AM
Unknown Object (File)
Sep 1 2024, 7:09 PM
Unknown Object (File)
Aug 14 2024, 3:32 PM
Subscribers

Details

Summary

Use sched_wakeup instead of sched_add when marking an ithread
runnable. This allows schedulers to reset their internal time slice
tracking state and restore the base ithread priority when an ithread
resumes from idle.

Sponsored by: Netflix

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

jhb requested review of this revision.Jun 28 2022, 10:31 PM

So this change would be not needed if you do the prio adjustments in sched_add(). I think more explanations are needed if there is a reason to handle ithreads prio in sched_wakeup(). Is it just a micro-optimization to avoid one more if() in sched_add()?

One more if that would end up duplicating logic. However, it's also true that you don't want to do it on every sched_add(). For example, if an ithread is preempted the old thread gets put on the runqueues via sched_add() and you don't want that step to reset the scheduler's internal notion of CPU usage (how much of a time slice has been used). You only want to reset the usage back to zero when the ithread goes idle. In practice though it is simpler to mimic what happens now for other threads which is to reset it not when going idle, but when resumed from being idle. This is how it works today for other threads that only reset their time slice usage when resumed from sleeping, not every time they are put on a run queue.

This revision is now accepted and ready to land.Jul 12 2022, 1:31 PM