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

11–20 of 79 posts

Re: Zircon Fair Scheduler

#11

Post by monocasa »

terryschiavo22 wrote: post #3
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!

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…

Well, they're not moving away from Android per se. ART is being ported to run on fuschia.

Re: Zircon Fair Scheduler

#12

Post by VanillaCafe »

> 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 for later in the Zircon scheduler development cycle.

Those seem like important workloads. Does this imply that the deadline scheduler runs concurrently with the fair scheduler? Otherwise, what's the point of developing an ideal scheduler for common workloads if it cannot be used for critical workloads. Is it common to run two different schedulers in the same system?

Re: Zircon Fair Scheduler

#13

Post by monocasa »

endorphone wrote: post #10
pjmlp wrote: post #6

Earlier quoted context omitted.

It is very easy to convince the public, OEMs are the ones that need to be convinced. ART is already being ported into Fuchsia and Linuxisms are not part of NDK stable APIs. So managed Android apps will just work, and NDK libraries only need to be recompiled.

In that case it wouldn't have replaced Android at all -- It would have simply replaced the Android kernel, which happens to be Linux. And at that point you have to ask what is gained, and at this point the answer is "nothing".

Well a change of the kernel's license from GPLv2 to BSD is certainly a change. I'm sure the OEMs think that gains them something.

Re: Zircon Fair Scheduler

#14

Post by wolfgke »

endorphone wrote: post #10
pjmlp wrote: post #6

Earlier quoted context omitted.

It is very easy to convince the public, OEMs are the ones that need to be convinced. ART is already being ported into Fuchsia and Linuxisms are not part of NDK stable APIs. So managed Android apps will just work, and NDK libraries only need to be recompiled.

In that case it wouldn't have replaced Android at all -- It would have simply replaced the Android kernel, which happens to be Linux. And at that point you have to ask what is gained, and at this point the answer is "nothing".

> And at that point you have to ask what is gained, and at this point the answer is "nothing".

Not having to care about the permanent breaking of internal kernel APIs is not "nothing".

Re: Zircon Fair Scheduler

#15

Post by endorphone »

wolfgke wrote: post #14
endorphone wrote: post #10

Earlier quoted context omitted.

In that case it wouldn't have replaced Android at all -- It would have simply replaced the Android kernel, which happens to be Linux. And at that point you have to ask what is gained, and at this point the answer is "nothing".

> And at that point you have to ask what is gained, and at this point the answer is "nothing". Not having to care about the permanent breaking of internal kernel APIs is not "nothing".

How, exactly, will they "not have to care"? The identical ramifications occur with Fuscia as they happen with Linux! This is farce.

Every single problem that Android has had, from low-latency audio issues (they've rebuilt that a dozen times in a dozen cartoonish ways) to driver stagnancy, is completely and directly a result of Google choices and implementations (and they do the same thing again and again! It's remarkable). The notion that Google is going to fix all of their own self-sabotage by starting anew is comedic in a sense, and is the folly of countless foolish projects. "We keep fucking up again and again...let's start from scratch and this time we'll surely do it right!"

This time, however, it'll be different...

Re: Zircon Fair Scheduler

#16

Post by colechristensen »

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.

Re: Zircon Fair Scheduler

#17

Post by endorphone »

monocasa wrote: post #13
endorphone wrote: post #10

Earlier quoted context omitted.

In that case it wouldn't have replaced Android at all -- It would have simply replaced the Android kernel, which happens to be Linux. And at that point you have to ask what is gained, and at this point the answer is "nothing".

Well a change of the kernel's license from GPLv2 to BSD is certainly a change. I'm sure the OEMs think that gains them something.

Android OEMs are not in the business of writing kernels, though, and the changes they do are minimal. And their HAL/chipset code -- the thing they might actually care about as IP -- is not governed by the GPL at all, nor is any of the enormous volume of system and userspace code they write.

It's a neat initiative and might yield something interesting, but if the Linux kernel was replaced by Fuscia the ramifications are seemingly very minor. Android's many issues have never been at the kernel level.

Re: Zircon Fair Scheduler

#18

Post by terryschiavo22 »

endorphone wrote: post #9
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…

Nothing, at all, has demonstrated that they plan it to replace Android -- that was a narrative various tech blogs invented. Nor would it have any benefit in moving away from the Java inspired/cloned underpinnings of the Android user layer. Google has a variety of initiatives, and they really like reinventing things (which can sometimes yield great outcomes). This is a kernel that is in contrast with Linux.

https://www.tomsguide.com/us/google-fuchsia-os-replace-andro...

From the article, the OS allows for full compatibility with all Android apps. Furthermore, it notes that Google is going out of its way to avoid mentioning Android anymore.

Of course, if I were Google and trying to sell the public on my new OS, I'd want them all to think that I'm not scrapping the old OS so that they feel they have a choice.

Re: Zircon Fair Scheduler

#19

Post by VanillaCafe »

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.

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?

Re: Zircon Fair Scheduler

#20

Post by monocasa »

endorphone wrote: post #17
monocasa wrote: post #13

Earlier quoted context omitted.

Well a change of the kernel's license from GPLv2 to BSD is certainly a change. I'm sure the OEMs think that gains them something.

Android OEMs are not in the business of writing kernels, though, and the changes they do are minimal. And their HAL/chipset code -- the thing they might actually care about as IP -- is not governed by the GPL at all, nor is any of the enormous volume of system and userspace code they write. It's a neat initiative and might yield something interesting, but if the Linux kernel was replaced by Fuscia the ramifications a…

The components of their HAL/chipset code in the kernel are most of the time governed by the GPL. We can take some examples apart of need be.
Post reply on HN