The Battle of the Schedulers: FreeBSD ULE vs. Linux CFS [pdf]

https://www.usenix.org/system/files/conference/atc18/atc18-bouron.pdf

by kev009 • 8 years ago

90 14 8 years ago

otterley• 8 years ago

"Conclusion: Scheduling threads on a multicore machine is hard."

Kudos to the kernel developers who have tried nearly everything under the sun to make performance of multi-core, multi-task, general-purpose machines satisfy everyone at the same time. Your efforts are not lost on those of us who understand just how difficult that is.

tzs• 8 years ago

Heck, even scheduling on single core machines can be hard. I don't want to even try to imagine what hell multicore adds to the mix.

In the late '80s I worked at Interactive System Corporation, the company that AT&T contracted with to do the official System V Release 3 port from the 3B2 to Intel processors. I was initially working on the port to the 286.

The 3B2 was a paging system, which did not really fit well with the 286, so it has kind of hacky. We never were able to get the scheduling to behave reasonably. Running 10 CPU bound tasks, for example, would result in one getting about 85% of the CPU, another getting about 10%, and the other 8 splitting pretty evenly the rest. It would do this for a while and then would start massively thrashing swap for a couple minutes, and then would settle back down to the 85/10/* but with different tasks getting the 85 and 10.

We were still stuck on figuring that out when AT&T came to their senses and realized that no one actually wanted System V Release 3 on a 286 and we dropped it. At most what they wanted was to run their 286 Xenix and 286 System III binaries on their 386 System V Release 3 systems, and I got moved over to working on the emulators for those, which was much more pleasant.

(Besides multicore, another thing that I would guess makes it all much harder for today's kernel people is caching. Caching on the 286, and even 386, was a lot simpler than it is today. We were still in the days when systems were primarily getting faster because clock speeds were going up, not because they were being smarter. Now I think they get a lot of performance from very good use of resources, such as cache, and it is a lot easier in kernel software therefore to blow performance).

B1FF_PSUVM• 8 years ago

At most what they wanted was [...]

And there goes a large slice of all wasted engineering effort ...

Aloha• 8 years ago

I'm actually amazed you were able to get SysVRIII working on a 286 at all.

I'm actually kinda curious about the details on Porting System V, the 3B2 is a machine I find super interesting.

pietroglyph• 8 years ago

"The Linux kernel offers an API to add new schedulers to the kernel. ... [In Linux] multiple schedul- ing classes can co-exist"

Very cool! Are there any real-world applications that use non-default/custom schedulers?

mav3rick• 8 years ago

Real time systems can have different scheduling metric based on utilization and/or deadlines.

kev009• 8 years ago

Con Kolivas' schedulers have had a loyal following among some desktop users http://www.users.on.net/~ckolivas/kernel/

DiabloD3• 8 years ago

Most people don't know this, but #ck exists on OFTC.

inferiorhuman• 8 years ago

Custom Android distributions like Cyanogenmod IIRC

AstralStorm• 8 years ago

Real-time branch of Linux by Ingo Molnar as well, that version of CFS works somewhat differently.

Then you have some other RT Linux versions and VM schedulers in Xen.

modzu• 8 years ago

i read this as battle of the shredders. like, a proper shred is hard isnt it. you need to disperse the shreds. youd think by now wed have fully entropic shredders that slowly burn the paper as it goes through

cozzyd• 8 years ago

It's amusing that they fixed several bugs in the schedulers while writing this paper.

b2ccb2• 8 years ago

The FreeBSD bug report and patch for reference:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223914

Wildgoose• 8 years ago

It would be interesting to compare this with DragonflyBSD seeing as Matt Dillon expressly forked FreeBSD over disagreements about how best to handle multiple cores.

The Battle of the Schedulers: FreeBSD ULE vs. Linux CFS [pdf]

Related Stories