BMQ "BitMap Queue" Is The Newest Linux CPU Scheduler, Inspired By Google's Zircon

[phoronix]

Phoronix: BMQ "BitMap Queue" Is The Newest Linux CPU Scheduler, Inspired By Google's Zircon

While there is the MuQSS CPU scheduler that lives out of tree as a promising CPU scheduler for the Linux kernel, it is not alone. Another option has been the PDS scheduler while now its author, Alfred Chen, has announced another new CPU kernel scheduler option he has dubbed the BitMap Queue...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-BitMap-Queue-BMQ

[bartturner]

Visited the blog post and what is not clear to me is what makes this like the Zircon scheduler? The Zircon kernel is so different than the Linux kernel inherently. Zircon is preemptable and also supports pre-empting other cores. Linux by default does neither.

Plus Zircon is just so different than Linux in so many other ways it seems strange that a scheduler on one would be that valuable on the other? Linux I/O executes on the same core requesting for example. Versus every I/O on Zircon involves an IPC and you use shared memory and can therefore do a type of pipelining.

I am super curious on the title and hoping it is not some clickbait thing. I would not have spent time on this if there was not the "Zircon" in the title. I am super excited about Zircon.

[ms178]

I guess this topic needs some benchmark numbers to see how good these different schedulers work in real world workloads.

[cl333r]

Meh, I wonder if there's a quick way to enable bfq on Ubuntu (18.10 or 19.04), last time I checked it wasn't simple and didn't work.

[flower]

I am super excited about Zircon.

why?
i would prefer google would invest more dev-power in linux.

[Wojcian]

Visited the blog post and what is not clear to me is what makes this like the Zircon scheduler? The Zircon kernel is so different than the Linux kernel inherently. Zircon is preemptable and also supports pre-empting other cores. Linux by default does neither.

Linux is preemptable as well. I'm not sure what you meant by 'default'.

Linux I/O executes on the same core requesting for example. Versus every I/O on Zircon involves an IPC and you use shared memory and can therefore do a type of pipelining.

Seems like a lot of context switching. Uring on Linux is exciting.

[bartturner]

why?
i would prefer google would invest more dev-power in linux.

Think they are doing both. But also feel like it is time for a new kernel. Really like where they are going with Zircon. This idea of breaking up what happens in the kernel to run on multiple cores and use shared memory to coordinate.

This will help with our biggest issue is today with the slow speed of accessing memory. I do hope Google also does a new SoC that is optimized for Zircon. There is design decisions that make sense for Zircon that would not for Linux.

[M@yeulC]

Think they are doing both. But also feel like it is time for a new kernel. Really like where they are going with Zircon. This idea of breaking up what happens in the kernel to run on multiple cores and use shared memory to coordinate.

This will help with our biggest issue is today with the slow speed of accessing memory. I do hope Google also does a new SoC that is optimized for Zircon. There is design decisions that make sense for Zircon that would not for Linux.

I like microkernels. I hate Zircon's licensing choice.

[bartturner]

Linux is preemptable as well. I'm not sure what you meant by 'default'.



Seems like a lot of context switching. Uring on Linux is exciting.

Depends. If already executing on another core there is no context switch. Plus having a function specific to a core instead of executing on all the cores helps lower needing to go back to memory for instructions. Easier to keep instruction cache hot.

What I like seeing is some innovation and doing new things. The kernels we are using architecture has not changed. I love Linux but also like to see something new.

[PuckPoltergeist]

Depends. If already executing on another core there is no context switch. Plus having a function specific to a core instead of executing on all the cores helps lower needing to go back to memory for instructions. Easier to keep instruction cache hot.

It's very confusing what you're writing. What do you mean with "already executing on another core there is no context switch"? What is "a function specific to a core"?