Zircon Fair Scheduler
fuchsia.googlesource.com
fuchsia.googlesource.com
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?
You can approximate the choice down to two dimensions, latency vs. throughput. Pick your poison.
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?
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.
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.
Two of my primary areas of interest, audio engineering and VR both REALLY show how poorly modern operating systems do with user interactivity when it counts.
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.
Google may have some intention of running Fuschia on servers, but even if you're developing a kernel for pocket mobile devices, you're still going to want to handle multiple cores.
Whether this signals Google's intentions to stop supporting Linux, who knows, but there are still a lot of other organizations invested in supporting Linux on servers.
I don't think manufacturers of devices can bet their futures on Google.
1: https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on...
They don't mean multi-socket systems, and I don't see mention of NUMA, which is the interesting case for servers where RAM is connected to some memory controller in a socket and to reach it from a CPU in a different socket you need to do extra hops, so some memory addresses are more distance than others and schedulers should take that into account to achieve good performance.
https://lwn.net/Articles/501501/ has some pointers.
And by "fun" I mean not-fun, because you've got multiple build processes and releases to manage.
Thinking of running that as a single multiprocessing system I'm reminded of the bug caused by Samsung doing big.LITTLE with cores that have the same instruction set but differently sized cache lines: https://news.ycombinator.com/item?id=12481700
Right, I didn't mean to imply otherwise.
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. There's certainly some really interesting potential around that.
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...
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.
Of course, they could have just meme'd hard about the fact that they're moving away from evil Oracle technology and we'd have already all been on board.
Can you point me to anything that demonstrates that intention?
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.
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.
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.
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.
I'm going to go out on a limb here and guess that you don't actually write kernel drivers like I do professionally.
Nice.
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.
As for systems programming experience, you would be surprised, but I am not here to justify myself with appeals to authority.
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.
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.
That reasoning doesn't apply to most kernel drivers, and those vendors are just openly in conflict with the GPL.
Not having to care about the permanent breaking of internal kernel APIs is not "nothing".
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...
But they didn't. They kept keeping it in sync. They probably had a reason for doing that.
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.
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.
The article does not say that. The article mentions an ART target for Fuscia -- you have to build from something. That is approximately 0.1% of the way towards full compatibility. And for that matter you can run Android apps on a load of targets (although far from full compatibility), but that doesn't mean that they're replacing Android.
Google may absolutely replace Android -- they've made loads and loads of mistakes along the way -- but the way people keep arguing it doesn't make sense, using examples that jettison the parts that work well and somehow keep the parts that don't work well (which includes ART, as an aside). And indeed I'm falling into this same trap while talking about Fuscia like it's a kernel, when really the kernel is a small part and they're, at a very small scale, spit-boarding a new take on virtually every part of the system.
Regarding Google distancing itself from the Android name, that's just branding. To quote one analysis -- "Android sounds technical, has baggage, and might be stale". They've had enough missteps that it's an anchor more than a lift, so it makes sense that they stop highlighting it.
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.
Also though, I do love it. Different strokes and all
I've never had a higher-end phone, so I'm not missing anything with the mid-range. Web works great, as do most apps.
The kernel is designed to have a stable binary interface for drivers. This has been a problem with Linux-based Android devices (all of them so far), because the OEMs (or more properly the chipset vendors like Qualcomm) will only support a particular chipset for a short amount of time (maybe a couple years, it depends).
After that, it becomes hard to bring new kernels to the platform, so we all end up with phones stuck at whatever major release was out at the time, with low prospects of upgrades.
If you can make a stable binary API, and furthermore keep to the micro-kernel model, then most of the OS can be easily upgraded, because you don't need (and aren't going to get) new versions of the device drivers for the chipset.
Also, there's an effort towards better low-latency real-time support. This is critical for AR/VR applications with tight rendering deadlines.
And Fuchsia is mikrokernel based.