Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zircon Fair Scheduler

fuchsia.googlesource.com

Post reply on HN
Print view View original

51–60 of 79 posts

Re: Zircon Fair Scheduler

#51

Post by derefr »

VanillaCafe wrote: post #12

> A NOTE ABOUT DEADLINES: While fair scheduling is appropriate for the vast majority of workloads, there are some tasks that require very specific timing and/or do not adapt well to overload conditions. For example, these workloads include low-latency audio / graphics, high-frequency sensors, and high-rate / low-latency networking. These specialized tasks are better served with a deadline scheduler, which is planned…

Yes, it's common, though in many cases it's an implicit rather than explicit part of the design—"deadline scheduling" is just what happens when you allow kernel-mode drivers to register CPU interrupts (usually, these days, coming from DMA completion events.)

Re: Zircon Fair Scheduler

#52

Post by pjmlp »

monocasa wrote: post #48
pjmlp wrote: post #46

Earlier quoted context omitted.

Again, yes there are drivers running in the kernel space, yes they are mostly GPL, no Google isn't re-writing them into Binderized HALs, they can stay as Passthrough HALs. Nothing of that prevents that all new drivers, except for the ones marked as legacy, are required to be Binderized. The kernel code of a driver from OEMs allergic to GPL, is hardly different from a signal handler, implementing the minimal set of ke…

Sort of... I'm going to go out on a limb here and guess that you don't actually write kernel drivers like I do professionally.

Ah appealing to authority as last argument, naturally any kind of opinion and knowledge of what I might have as Android developer, or former professional experience in systems programming is worthless.

Nice.

Re: Zircon Fair Scheduler

#53

Post by tonfa »

wolf550e wrote: post #33
impostir wrote: post #26

There are many references to multiple cpu systems throughout the document. Maybe I missed something, but I didn't know Fuschia was aimed at systems like that. I am no expert, but aren't the vast majority of multiple cpu systems servers or high-rnd workstations? If google can supply their own server os, Linux could lose a lot of support and funding

"cpu" is "core". Almost all phone CPUs are multi-core. The low end of phone (and Raspberry Pi 2 V1.2 and newer) CPUs is quad core ARM Cortex A53, which is a small slow in-order design, similar to the original Intel Pentium from 1995. Older low end phones used the 32bit quad core ARM Cortex-A7. single core ARM11 phones are extinct. They don't mean multi-socket systems, and I don't see mention of NUMA, which is the int…

And phone CPUs can be more complex than most desktops, afaik big.LITTLE is fairly common (multi core, with different performance / power tradeoffs between the cores).

https://lwn.net/Articles/501501/ has some pointers.

Re: Zircon Fair Scheduler

#54

Post by coreytabaka »

VanillaCafe wrote: post #47
coreytabaka wrote: post #28

Earlier quoted context omitted.

It does imply that. Multiple concurrent scheduling algorithms is nothing new, Linux and MacOS both support per-thread algorithm selection.

What does the super scheduler that coordinates the two schedulers approximately look like?

A simple hierarchy: when there is deadline work to do that work takes precedence, fair work gets the rest of the time. This is effective because deadline work has bounded execution time, whereas fair work is elastic and can adjust to use the available bandwidth.

Re: Zircon Fair Scheduler

#55

Post by the8472 »

VanillaCafe wrote: post #47
coreytabaka wrote: post #28

Earlier quoted context omitted.

It does imply that. Multiple concurrent scheduling algorithms is nothing new, Linux and MacOS both support per-thread algorithm selection.

What does the super scheduler that coordinates the two schedulers approximately look like?

RT tasks get prioritized over normal ones but only up to a configurable fraction of CPU time slices.

If you need even more guarantees than that another option is to pin tasks to a set of CPU cores to isolate workloads from each other. The kernel can also be told to not use certain cores for interrupt handling or kernel-internal tasks. So with some effort it's possible to almost entirely dedicate a core to a single thread.

Re: Zircon Fair Scheduler

#56

Post by monocasa »

pjmlp wrote: post #52
monocasa wrote: post #48

Earlier quoted context omitted.

Sort of... I'm going to go out on a limb here and guess that you don't actually write kernel drivers like I do professionally.

Ah appealing to authority as last argument, naturally any kind of opinion and knowledge of what I might have as Android developer, or former professional experience in systems programming is worthless. Nice.

More that I recognized a position that comes from a cursory understanding of the situation. About the level I'd expect from having taken a few classes on it, but lacks true experience in the domain. One of those "in theory, theory and practice are the same. In practice, they're not" sort of situations. You've taken those ideas to conclusions that could have been valid, but the industry took other options.

Now, as someone who has spent a decade in that domain, I'm down to continue having a conversation about it and helping overcome a few of those hurdles, but you need to be willing to hear something that isn't your own conclusions.

Re: Zircon Fair Scheduler

#57

Post by geodel »

linuxftw wrote: post #32
impostir wrote: post #26

There are many references to multiple cpu systems throughout the document. Maybe I missed something, but I didn't know Fuschia was aimed at systems like that. I am no expert, but aren't the vast majority of multiple cpu systems servers or high-rnd workstations? If google can supply their own server os, Linux could lose a lot of support and funding

Hopefully the industry learned it's lesson with Google and it's handling of the Android Open Source Project [1]. I don't think manufacturers of devices can bet their futures on Google. 1: https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on...

Well Samsung wrote their wonderful OS named Tizen. Not sure why they still sell Android phones. And if company as big as Samsung couldn't do it then lesson for industry would be that writing OS for their hardware is pretty much guaranteed failure.

Re: Zircon Fair Scheduler

#58

Post by wolf550e »

tonfa wrote: post #53
wolf550e wrote: post #33

Earlier quoted context omitted.

"cpu" is "core". Almost all phone CPUs are multi-core. The low end of phone (and Raspberry Pi 2 V1.2 and newer) CPUs is quad core ARM Cortex A53, which is a small slow in-order design, similar to the original Intel Pentium from 1995. Older low end phones used the 32bit quad core ARM Cortex-A7. single core ARM11 phones are extinct. They don't mean multi-socket systems, and I don't see mention of NUMA, which is the int…

And phone CPUs can be more complex than most desktops, afaik big.LITTLE is fairly common (multi core, with different performance / power tradeoffs between the cores). https://lwn.net/Articles/501501/ has some pointers.

I was just saying the low end chips have only "little" cores, no "big" cores, but they are still multi-core. AFAIK nobody makes single core Cortex A chips. Single core Cortex M chips are made, but those are really puny.

Re: Zircon Fair Scheduler

#59

Post by pjmlp »

monocasa wrote: post #56
pjmlp wrote: post #52

Earlier quoted context omitted.

Ah appealing to authority as last argument, naturally any kind of opinion and knowledge of what I might have as Android developer, or former professional experience in systems programming is worthless. Nice.

More that I recognized a position that comes from a cursory understanding of the situation. About the level I'd expect from having taken a few classes on it, but lacks true experience in the domain. One of those "in theory, theory and practice are the same. In practice, they're not" sort of situations. You've taken those ideas to conclusions that could have been valid, but the industry took other options. Now, as som…

Just like you need to be willing to accept that GPL won't stay forever on Android, but you are right I don't have a clue.

As for systems programming experience, you would be surprised, but I am not here to justify myself with appeals to authority.

Re: Zircon Fair Scheduler

#60

Post by WhatIsDukkha »

coreytabaka wrote: post #54
VanillaCafe wrote: post #47

Earlier quoted context omitted.

What does the super scheduler that coordinates the two schedulers approximately look like?

A simple hierarchy: when there is deadline work to do that work takes precedence, fair work gets the rest of the time. This is effective because deadline work has bounded execution time, whereas fair work is elastic and can adjust to use the available bandwidth.

Where is io scheduling in this?

It's my perception that on current workstations, for example, that and "ionice -c3" in front of any build I do is far more useful then simply nicing it.

Post reply on HN