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

41–50 of 79 posts

Re: Zircon Fair Scheduler

#41

Post by stronglikedan »

shereadsthenews wrote: post #27
terryschiavo22 wrote: post #3

Earlier quoted context omitted.

Well, Google intends for this new OS to replace Android. They'll need to convince the public that this new OS is somehow better than Android, which everyone has come to know and love. It seems that they believe the best way to do that is a grassroots approach beginning with tech discussion hubs like HN and Reddit. Of course, they could have just meme'd hard about the fact that they're moving away from evil Oracle tec…

> Android, which everyone has come to know and love. Haha, honestly now. If my Android didn't cost $700 I would long since have smashed it to bits. It's scheduler is totally garbage, to the point where Google's own media apps like YouTube and Music drop samples while the screen is redrawing. Who "loves" Android? To me it is the Win98 of mobile operating systems.

When you only have two real choices, each with their own significant set of distinct problems, I think the term "love" can be substituted for "hate the least". Android, which everyone has come to know and hate the least. Well, not everyone, but my point is the same regardless.

Re: Zircon Fair Scheduler

#42

Post by rhizome »

dpflan wrote: post #2

This post has sky-rocketed to the top! I'm genuinely curious: can someone explain what's cool/interesting/important about this (maybe EL5)? Thanks!

tl;dr: Good question, it's not answered anywhere in the family of repositories that Zircon touches.

Re: Zircon Fair Scheduler

#43

Post by monocasa »

pjmlp wrote: post #38
monocasa wrote: post #30

Earlier quoted context omitted.

Even fully after Treble, there are absolutely still kernel drivers.

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.

Re: Zircon Fair Scheduler

#44

Post by pjmlp »

stronglikedan wrote: post #41
shereadsthenews wrote: post #27

Earlier quoted context omitted.

> Android, which everyone has come to know and love. Haha, honestly now. If my Android didn't cost $700 I would long since have smashed it to bits. It's scheduler is totally garbage, to the point where Google's own media apps like YouTube and Music drop samples while the screen is redrawing. Who "loves" Android? To me it is the Win98 of mobile operating systems.

When you only have two real choices, each with their own significant set of distinct problems, I think the term "love" can be substituted for "hate the least". Android, which everyone has come to know and hate the least . Well, not everyone , but my point is the same regardless.

I left Symbian for Android 2.1, after several Android devices, became part of the 10% of WP share in Europe, now still using one of them as secondary device.

Re: Zircon Fair Scheduler

#45

Post by monocasa »

endorphone wrote: post #39
monocasa wrote: post #30

Earlier quoted context omitted.

Even fully after Treble, there are absolutely still kernel drivers.

Qualcomm has no obligation to GPL their kernel drivers. Nor does nvidia, or any other KLM maker. This has never demanded that kernel drivers be open sourced. That's why it's impossible to make a runnable AOSP image for many devices. Vendors still make generally minor changes to the kernel, but these are not unique or special or some competitive edge. They've just nuisance necessities.

It's way more grey than that. Nvidia claims that their driver doesn't need to be opened because since it's A) from a codebase that existed prior to the Linux port, and B) doesn't actually import any Linux code or symbols (that's left to a dual licensed shim layer), that in a legal sense their driver isn't 'derived from' the Linux kernel and isn't subject to the viral parts of the GPL. And, all of this is the greyest of grey area. Towards that end, Nvidia has been committing to Nouveau lately for Tegra chips because I think they realize how precarious their legal situation is for chips essientially designed to run Linux.

That reasoning doesn't apply to most kernel drivers, and those vendors are just openly in conflict with the GPL.

Re: Zircon Fair Scheduler

#46

Post by pjmlp »

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.

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 kernel code and deferring everything else to userspace.

Re: Zircon Fair Scheduler

#47

Post by VanillaCafe »

coreytabaka wrote: post #28
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…

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?

Re: Zircon Fair Scheduler

#48

Post by monocasa »

pjmlp wrote: post #46
monocasa wrote: post #43

Earlier quoted context omitted.

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.

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.

Re: Zircon Fair Scheduler

#49

Post by tathougies »

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

Anecdata, but my tiny ARM server at home has eight cores on one SOC and costs $80. I believe my phone also has eight cores.

Re: Zircon Fair Scheduler

#50

Post by colechristensen »

VanillaCafe wrote: post #19
colechristensen wrote: post #16

Earlier quoted context omitted.

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.

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 scheduler for one that could guarantee the deadlines you need are met. Sacrificing "performance" that is throughput/efficiency/etc of your processor for timing performance.

Think of the difference between doing statistics on a billion lines of data and flight controls on a missile. VERY different needs for scheduling, why not have a selectable algorithm?

Post reply on HN