Re: Current ULE state and plans (was Re: HMP scheduling on FreeBSD)
- In reply to: Steve Kargl : "Re: Current ULE state and plans (was Re: HMP scheduling on FreeBSD)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 21 Jan 2026 18:16:54 UTC
> I don't see emotional responses. Perhaps because you are subject to that effect as well? > Why does 4BSD have to be**significantly better** than > ULE? What if 4BSD performs on-par with ULE? Can you please explain what is the point of keeping 4BSD if it's not better than ULE in anything? > In another response, you noted that you're concentrating > on testing ULE. That's fine. But, you also wrote "I did > not do that for 4BSD, just basic smoke tests and that's > all." Again, that's fine. There is only so much time in > a day. But, to draw the conclusion that ULE is better > than 4BSD, and therefore 4BSD should be removed in FreeBSD > 16 seems a bit suspect. I didn't draw that conclusion at all from the premises you exposed, but rather the one that ULE is much more tested and in many more scenarios than 4BSD. In that sense, that makes it "better", yes. The conclusion that ULE is overall better than 4BSD performance-wise was drawn a long time ago and repeatedly. There is Jeff's original paper: https://papers.freebsd.org/2003/BSDCon/jeff-ule_scheduler.files/jeff-ule_scheduler-paper.pdf, which I concede is quite old now (2003), showing synthetic tests but also mentioning a significant performance improvement of 30% for web serving. You can find more performance comparison between 4BSD and ULE from 2008 in some of the documents here: https://people.freebsd.org/~kris/scaling/smp.html, for database and network performance. There are more recent indirect hints, such as ULE's comparison with Linux's CFS (https://www.usenix.org/system/files/conference/atc18/atc18-bouron.pdf), showing the former performs better. 'make -jXX buildworld' is also a simple test that everybody can run and produces clear results. That said, it would be nice to run a new series of experiments for comparison, before 16, so that either everybody gets finally convinced there's no performance point in keeping 4BSD or we find some real remaining issues. Finally, deprecating 4BSD in 16 does not mean removing it in 16. -- Olivier Certner