Con Kolivas releases BFS, alternative to mainline scheduler • Hacker News Board

Re: Con Kolivas releases BFS, alternative to mainline scheduler

#21

Post by ZeroGravitas » Wed, Sep 02, 2009, 9:37 AM UTC

ekiru wrote: post #7

MikeW wrote: post #3

Good to see Con back. But three letter acronyms have too many collisions and this is one of those cases. As soon as I saw the title of this post, I was instantly reminded of BFS - the Be File System http://en.wikipedia.org/wiki/Be_File_System Although in this case it's a Kernel scheduler rather than a Kernel mode Filesystem driver (even though Linux already has kernel module named bfs - Boot File System!) - indeed a…

Was your use of an acronym for three letter acronym that is ambiguous and could refer to two letter acronyms, three letter acronyms, or even three-hundred letter acronyms intentional?

And it's not even an acronym, it's an initialism!

http://en.wikipedia.org/wiki/Acronym_and_initialism

Re: Con Kolivas releases BFS, alternative to mainline scheduler

#22

Post by Hexstream » Wed, Sep 02, 2009, 12:52 PM UTC

"With a truckload of help from William Lee Irwin III (who wrote the main architecture) I posted a pluggable CPU scheduler framework that would allow you to build into the kernel as many of multiple CPU schedulers as you like and choose at boot time which one to run. I planned to extend that to runtime selection as well. This is much like the modular pluggable I/O scheduler framework that Linux kernel currently has. It was flat out refused by both Linus and Ingo (who is the CPU scheduler maintainer) as leading to specialisation of CPU schedulers and they both preferred there to be one CPU scheduler that was good at everything. I guess you can say the CPU scheduler is a steamroller that we as desktop users use to crack nuts with, and they didn't want us to build a nutcracker into the kernel."

o_o

Re: Con Kolivas releases BFS, alternative to mainline scheduler

#23

Post by jacquesm » Wed, Sep 02, 2009, 2:52 PM UTC

Hexstream wrote: post #22

"With a truckload of help from William Lee Irwin III (who wrote the main architecture) I posted a pluggable CPU scheduler framework that would allow you to build into the kernel as many of multiple CPU schedulers as you like and choose at boot time which one to run. I planned to extend that to runtime selection as well. This is much like the modular pluggable I/O scheduler framework that Linux kernel currently has. I…

It looks like HN is 800K compliant.

Congratulations.

Re: Con Kolivas releases BFS, alternative to mainline scheduler

#24

Post by Hexstream » Thu, Sep 03, 2009, 1:29 PM UTC

jacquesm wrote: post #23

Hexstream wrote: post #22

"With a truckload of help from William Lee Irwin III (who wrote the main architecture) I posted a pluggable CPU scheduler framework that would allow you to build into the kernel as many of multiple CPU schedulers as you like and choose at boot time which one to run. I planned to extend that to runtime selection as well. This is much like the modular pluggable I/O scheduler framework that Linux kernel currently has. I…

It looks like HN is 800K compliant. Congratulations.

???

Re: Con Kolivas releases BFS, alternative to mainline scheduler

#25

Post by nitrogen » Fri, Sep 04, 2009, 11:21 AM UTC

blasdel wrote: post #18

nitrogen wrote: post #5

This is very exciting. I use Linux on my desktop, laptop, servers, and embedded devices. I was getting kind of tired of the latency tradeoffs made to improve throughput. The kernel developers are really good at what they do, but like most geeks, sometimes they need a virtual kick in the head to realize that there might be a better way to do something. I'll be trying out his new scheduler as soon as I get a chance to…

It's not so much that the kernel devs are actively making "latency tradeoffs" -- it's that they absolutely can't get away with regressions It would be completely untenable if the corporate users (who are in the vast majority by every metric) ended up either not upgrading or using a fork that reverts the changes.

I suppose I see using a "one size fits all" scheduler as inherently full of tradeoffs between desktop, realtime, server, and 4096-core-compute-system requirements. IMO distributions and kernel hackers should be able to choose a scheduler that is optimal for their target audience. RHEL would probably stick with CFS, but Ubuntu Studio could use something more latency-oriented, like BFS.

Maybe if CK keeps bringing up the issue, eventually someone will figure out an optimal way of measuring perceived latency that will prove or disprove the anecdotes given by CK's "followers."