Date: Thu, 15 Jan 2026 19:03:16 +0000 From: Minsoo Choo <minsoochoo0122@proton.me> To: Olivier Certner <olce@freebsd.org> Cc: freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: HMP scheduling on FreeBSD Message-ID: <6tOKBjzm6105PhWG7uokCxT9_vl6KFcdZlDDZqLtJHLinaU79t1KirKeB0BU0PNg0iMFOQrbQoLLrfGQGw8ku2M-xpvO15tXI1WzdLAQ4m4=@proton.me> In-Reply-To: <1886427.OVFmXjEfDW@ravel> References: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> <1886427.OVFmXjEfDW@ravel>
index | next in thread | previous in thread | raw e-mail
On Wednesday, January 14th, 2026 at 5:15 PM, Olivier Certner <olce@freebsd.org> wrote: > > These are good first observations but they can only really apply in specific circumstances. Converting core's capacity in run queue length can only drive a loaded system, not a mostly idle one. This mechanism will also cause an increase in latency for threads running on performant cores. > > There are several theoretical considerations that should be met together, such as fairness, latency, bias to performance or to energy (policy), affinity, cpusets (directives), etc., and... > IMHO, ULE doesn't do great job for fairness. There was a freebsd-hackers thread [1] back in 2023 that criticized ULE's fairness, and I believe this is ULE's limitation by design. Someone in the thread said the interactivity score is "bogus": although I wouldn't go that far, interactivity score sacrifices fairness and we definitely need patches to handle edge cases (similar to what CFS experienced on linux side). ULE's interactivity score mechanism also pollutes priorities provided by nice value. Someone in the thread said nice isn't relevant anymore these days, but I think it should be respected as nice value is crucial to UNIX scheduling and many softwares still depend on it. Interactivity scores and nice value can be messed up together pretty easily compared to CFS/EEVDF, which can cause performance degradation that users didn't expect. It also makes harder to predict how the system would behave under certain circumstance while many of the "interactivity" assumptions in early 2000s aren't true anymore (e.g. graphical applications). It would be nice to introduce fairness scheduler like CFS/EEVDF[2] in FreeBSD, even though that might require cleaning up existing sched.h interfaces. FreeBSD kernel has been too dependent on 4BSD/ULE since early 2000s, and introducing new scheduler will break many things. By establishing a better sched interface, this gives opportunities for others to implement their own scheduler on FreeBSD. > > Before integrating scheduler and cpucap, I need to go through sched_ule.c from top to bottom. After that, I'll add new functions or drop existing ones from the cpucap framework then work on the integration. > > > ...there are some practical considerations too. ULE maintains per-CPU run queues and does inter-CPU thread exchange relatively infrequently (through the so-called "long-term long balancer") for fairness. It will not exchange two threads on two different cores if there are the only ones running, which again is unfair if the two cores have different performances. > > A general scheduler must cater to a variety of workloads, and it can be quite difficult to improve some characteristics without degrading others. We certainly don't want to rush things. > These days I'm leaning towards fairness schedulers over multilevel feedback queue. While fairness schedulers are general and take no assumption on workloads by default, MFQ incorporates components like interactivity score to boost performance under certain circumstances. This works well in NT and XNU kernel where 1) the OS is built for specific usage (GUI desktop) and 2) software they are shipped with OS like desktop managers can directly interact with the scheduler its use cases [3]. However, operating systems like FreeBSD and Linux run under different environments (server, router, GUI desktop, etc) and fairness scheduler is more suitable because it is "general". Although it sacrifices performance under certain circumstance (e.g. XNU scheduler handles Aqua better than EEVDF does for Wayland/Xorg), I believe on Unix world window manager developers should handle this through nice not by asking OS to expose scheduling APIs like XNU does. > I invite you to read the https://wiki.freebsd.org/Scheduler/Hybrid for a glimpse on some of the trade-offs involved and a wider perspective, which however is by no means complete and for which input from you and any other interested parties is welcome. > > Thanks and regards. > > -- > Olivier Certner [1] https://lists.freebsd.org/archives/freebsd-hackers/2023-March/001938.html [2] https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=805acf7726282721504c8f00575d91ebfd750564 [3] https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/scheduler/scheduler.htmlhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6tOKBjzm6105PhWG7uokCxT9_vl6KFcdZlDDZqLtJHLinaU79t1KirKeB0BU0PNg0iMFOQrbQoLLrfGQGw8ku2M-xpvO15tXI1WzdLAQ4m4=>