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

71–79 of 79 posts

Re: Zircon Fair Scheduler

#71

Post by cbetti »

colechristensen wrote: post #16
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…

Different scheduling algorithms and implementations have tradeoffs. Pick one based on your workload. No need to have only one for all applications. You can approximate the choice down to two dimensions, latency vs. throughput. Pick your poison.

Three. And they're blended, which makes the selection hard. Latency, throughput, tolerance for dropped work.

Re: Zircon Fair Scheduler

#73

Post by ansible »

wolf550e wrote: post #66
ansible wrote: post #62

Earlier quoted context omitted.

Hilariously, it is common to see some SoCs, like the i.MX8, have Cortex-A and Cortex-M cores. You can do fun stuff like run different operating systems on them too. They can be used for real-time applications, safety-critical functions, etc.. And by "fun" I mean not-fun, because you've got multiple build processes and releases to manage.

But I think that's not used as a multiprocessor, with threads getting scheduling on either (or both) depending on power policy. The embedded cores are, I think, used as separate systems running separate OS that happen to have access to the same DRAM, like a peripheral that can do DMA. Thinking of running that as a single multiprocessing system I'm reminded of the bug caused by Samsung doing big.LITTLE with cores that…

> But I think that's not used as a multiprocessor, with threads getting scheduling on either (or both) depending on power policy. The embedded cores are, I think, used as separate systems running separate OS that happen to have access to the same DRAM, like a peripheral that can do DMA.

Right, I didn't mean to imply otherwise.

Re: Zircon Fair Scheduler

#74

Post by jblow »

colechristensen wrote: post #50
VanillaCafe wrote: post #19

Earlier quoted context omitted.

For instance, I assume for instance a common workload that would otherwise benefit from the fair scheduler has a fair chance of wanting to do low latency audio. I believe Android has had this issue. As soon as the platform cares about low latency audio it would need to abandon the fair scheduler?

Low latency audio would fit for doing live or studio audio production, not necessarily watching videos, listening to music or doing video calls (where there is already network delay an order of magnitude larger than the scheduler would impart). "Low" will have context-dependent meaning. If you're doing low latency audio or flight controls on an aircraft for example, you would absolutely need to abandon the fair sched…

> (where there is already network delay an order of magnitude larger than the scheduler would impart)

Not the right way to think about it; the connection latency is irrelevant. What is relevant is that you need to play audio in sync with the video, and that audio is coming to you approximately simultaneously with the video it's meant to be synced with.

Re: Zircon Fair Scheduler

#75

Post by euyyn »

coreytabaka wrote: post #29
bepvte wrote: post #22

https://cchalpha.blogspot.com/2019/03/bmq-scheduler-call-out... Someone made a scheduler on linux based on some of the ideas here. Its included in the postfactum (linux-pf) patch set i believe, which might have packages for your distro.

No, that's based on the deprecated multi-level round-robin scheduler, which we find tremendously amusing. :)

Who's "we"?

Re: Zircon Fair Scheduler

#76

Post by jasonvorhe »

geodel wrote: post #57
linuxftw wrote: post #32

Earlier quoted context omitted.

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.

Tizen was a security laughing stock, iirc. This is from 2017: https://arstechnica.com/gadgets/2017/04/samsungs-tizen-is-ri...

Re: Zircon Fair Scheduler

#77

Post by endorphone »

monocasa wrote: post #43
pjmlp wrote: post #38

Earlier quoted context omitted.

Sure there are, they are known as "legacy HALs" on Project Treble documentation.

Literally any driver that has a piece that runs in interrupt context has to have (in part) a kernel mode driver under Linux. On top of that, GPUs generally have to have a kernel component, even under systems that put as much as possible under user mode like sel4, because they have their own MMUs that can subvert kernel integrity.

Linux has countless LKMs (modules that run in the kernel, but are not -- broadly -- bound by the GPL). Many, many are closed-source and proprietary. Others aren't because they don't have to be.

You hinted that this transgresses the GPL, and there are those that argue that virtually anything transgresses the GPL. But a lot of very large corporations say otherwise, and there have been zero successful challenges against it.

Re: Zircon Fair Scheduler

#78

Post by Twirrim »

wolf550e wrote: post #69
Twirrim wrote: post #68

Earlier quoted context omitted.

big.LITTLE is fascinating, and I'm somewhat curious to see if Apple tries to do something along those lines as it supposedly pushes towards ARM chips in their machines. Google have added some interesting stuff to Android to help it learn over time if tasks should be allocated to the bigger cores or the lower powered smaller ones, based on all sorts of metrics, and I believe this stuff is making its way upstream. Ther…

Apple chips are big.LITTLE too, at least since the 2016 A10 in the iPhone7. https://en.wikichip.org/wiki/apple/ax/a12 https://en.wikichip.org/wiki/apple/ax/a10 https://www.anandtech.com/show/13392/the-iphone-xs-xs-max-re...

Sure, I should be clear I was thinking about OSX and laptops/desktops, rather than mobile devices.

Re: Zircon Fair Scheduler

#79

Post by brandmeyer »

wolf550e wrote: post #66
ansible wrote: post #62

Earlier quoted context omitted.

Hilariously, it is common to see some SoCs, like the i.MX8, have Cortex-A and Cortex-M cores. You can do fun stuff like run different operating systems on them too. They can be used for real-time applications, safety-critical functions, etc.. And by "fun" I mean not-fun, because you've got multiple build processes and releases to manage.

But I think that's not used as a multiprocessor, with threads getting scheduling on either (or both) depending on power policy. The embedded cores are, I think, used as separate systems running separate OS that happen to have access to the same DRAM, like a peripheral that can do DMA. Thinking of running that as a single multiprocessing system I'm reminded of the bug caused by Samsung doing big.LITTLE with cores that…

There are variations on this theme where the two types of cores are also cache coherent with each other.
Post reply on HN