From nobody Thu Jan 15 19:03:16 2026 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dsXSY3zfQz6PKTF for ; Thu, 15 Jan 2026 19:03:25 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Received: from mail-106102.protonmail.ch (mail-106102.protonmail.ch [79.135.106.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dsXSY0w73z3tKy for ; Thu, 15 Jan 2026 19:03:25 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1768503802; x=1768763002; bh=CvLM2frZaZSIHYpPWmzzYYri2SnnmhDpznnZ2sQhYEo=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=W4g0mKBG58J/Bvje1WGj3DWsm4bnxBYgSsulXI/AzymIWAoT4egEo4p/kOajVhIHa 1YNpm4ThIjRV3t2jOzewoPNfe7sgsofepi7L1TFRtOd+rJNkmvr7WOe6nAc43MTQjN wNegEoD0xle/x/1n5ZWG7J5BEEzNg074r8T+DjVets6ruCU3pVhermNY93iuVJx3cT KKgkCPNqT1SywRkbNnoWEC1Cwf/UPjC7Xy4cGM1sNAGMcPvF2YMc8cPxCGjl23QIfq 9cjKCf7uCfhl1mYg7FncEXl4qF24A2/eYVjhdQwuIS3AwB/t/RHPxtHIz0g+LJkOTN vWZrNQphN7VSQ== Date: Thu, 15 Jan 2026 19:03:16 +0000 To: Olivier Certner From: Minsoo Choo Cc: freebsd-hackers 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> Feedback-ID: 45891198:user:proton X-Pm-Message-ID: 08d246c98536d5d4e9de582c9a60cbe9d30d78d2 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:79.135.106.0/24, country:CH] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dsXSY0w73z3tKy On Wednesday, January 14th, 2026 at 5:15 PM, Olivier Certner wrote: >=20 > These are good first observations but they can only really apply in speci= fic circumstances. Converting core's capacity in run queue length can only = drive a loaded system, not a mostly idle one. This mechanism will also caus= e an increase in latency for threads running on performant cores. >=20 > There are several theoretical considerations that should be met together,= such as fairness, latency, bias to performance or to energy (policy), affi= nity, cpusets (directives), etc., and... >=20 IMHO, ULE doesn't do great job for fairness. There was a freebsd-hackers th= read [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 s= core is "bogus": although I wouldn't go that far, interactivity score sacri= fices 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 ni= ce 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 sched= uling 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 h= arder to predict how the system would behave under certain circumstance whi= le many of the "interactivity" assumptions in early 2000s aren't true anymo= re (e.g. graphical applications). It would be nice to introduce fairness scheduler like CFS/EEVDF[2] in FreeB= SD, even though that might require cleaning up existing sched.h interfaces.= FreeBSD kernel has been too dependent on 4BSD/ULE since early 2000s, and i= ntroducing new scheduler will break many things. By establishing a better s= ched 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. >=20 >=20 > ...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 exchang= e two threads on two different cores if there are the only ones running, wh= ich again is unfair if the two cores have different performances. >=20 > A general scheduler must cater to a variety of workloads, and it can be q= uite difficult to improve some characteristics without degrading others. We= certainly don't want to rush things. >=20 These days I'm leaning towards fairness schedulers over multilevel feedback= queue. While fairness schedulers are general and take no assumption on wor= kloads by default, MFQ incorporates components like interactivity score to = boost performance under certain circumstances. This works well in NT and XN= U kernel where 1) the OS is built for specific usage (GUI desktop) and 2) s= oftware they are shipped with OS like desktop managers can directly interac= t with the scheduler its use cases [3]. However, operating systems like FreeBSD and Linux run under different envir= onments (server, router, GUI desktop, etc) and fairness scheduler is more s= uitable because it is "general". Although it sacrifices performance under c= ertain circumstance (e.g. XNU scheduler handles Aqua better than EEVDF does= for Wayland/Xorg), I believe on Unix world window manager developers shoul= d 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 h= owever is by no means complete and for which input from you and any other i= nterested parties is welcome. >=20 > Thanks and regards. >=20 > -- > Olivier Certner [1] https://lists.freebsd.org/archives/freebsd-hackers/2023-March/001938.ht= ml [2] https://citeseerx.ist.psu.edu/document?repid=3Drep1&type=3Dpdf&doi=3D80= 5acf7726282721504c8f00575d91ebfd750564 [3] https://developer.apple.com/library/archive/documentation/Darwin/Concep= tual/KernelProgramming/scheduler/scheduler.html