System76-Scheduler Is a New Pop!_OS Rust Effort To Improve Desktop Responsiveness (phoronix.com) 43
slack_justyb writes: "Quietly making its v1.0 debut yesterday was system76-scheduler as a Rust-written daemon aiming to improve Linux desktop responsiveness and catering to their Pop!_OS distribution," reports Phoronix.
The daemon will work with the kernel's CFS scheduler to give priority to components that System76 deems important for its distro. Out of the box, the scheduler will assign priority to the X.Org Server and desktop window managers/compositors, while pushing compilers and other background tasks lower. However, the scheduler will be configurable via Rusty Object Notation (RON) files found in /etc/system76-scheduler/assignments/ and /usr/share/system76-scheduler/assignments/.
Over on the GitHub page for the project, the team indicates that they are indeed making a trade-off from the default CFS to benefit Desktop configurations over the typical load a server might see.
The daemon will work with the kernel's CFS scheduler to give priority to components that System76 deems important for its distro. Out of the box, the scheduler will assign priority to the X.Org Server and desktop window managers/compositors, while pushing compilers and other background tasks lower. However, the scheduler will be configurable via Rusty Object Notation (RON) files found in /etc/system76-scheduler/assignments/ and /usr/share/system76-scheduler/assignments/.
Over on the GitHub page for the project, the team indicates that they are indeed making a trade-off from the default CFS to benefit Desktop configurations over the typical load a server might see.
Equity (Score:3, Funny)
Re: Equity (Score:2)
scheduler should be promoting equity, not giving special privileges.
You get a cookie, that is how any good scheduler works, but this one suffers Linux desktop-itis and isn't suited for a server, that does real work.
I wonder if they ever heard of ionice (Score:2)
I wonder if they ever heard of ionice and nice while at it. It would be intresting to know what they propose does better.
Re: (Score:3)
Re:I wonder if they ever heard of ionice (Score:4, Interesting)
Ya, I'm sure these guys have never heard of nice and ionice. Which are great tools for kids, amateur sysadmins, or neckbeards who earned their chops on AT&T UNIX back in the day with Ken Thompson et al.
The linux schedular is massively more complex than setting the nice attribute on a process. cgroups [man7.org], scheduling classes [man7.org] (SCHED_*) for starters.
Differentation background and foreground processes (Score:1)
Not another format (Score:4, Insightful)
Re: (Score:2)
That was exactly what i thought.
Sometimes i hear people mocking the windows registry and claiming how much simpler the linux configuration storage is....
I wonder when the number of json files in /etc/ will start to grow.
Re: (Score:2)
Re: (Score:1)
As bad as some obscene number of text configuration files jammed into /etc and /usr are, and despite the existence of a perfectly functional KV storage system like a registry (dconf)
Even dconf is a reinvention of a reinvention. I'd mention X resources but I'm sure something must've come before.
Just like putting enormous effort into reinventing build systems (because writing a compiler from scratch is too much?) and not actually managing surpass POSIX make in utility (as opposed to dressing the utility up to your liking for your convenience, and every package builder's despair), as crippled as that is, so is reinventing formats a pastime that ends up being more about NIH than about imp
Re: (Score:2)
The improvement is unrelated to text vs binaries. It's related to centralisation. Providing the binaries are openly defined and easily configurable that is just a distraction from the core issue: the system should be resistant to breakage and easier to manage, not more difficult.
The biggest problem with the windows registry for example is its insane complexity and size. It's actually a good example of how being a binary format doesn't actually make it fragile. It's big problem is it's not actually simple.
Re: (Score:1)
The improvement is unrelated to text vs binaries. It's related to centralisation. Providing the binaries are openly defined and easily configurable that is just a distraction from the core issue: the system should be resistant to breakage and easier to manage, not more difficult.
I wouldn't say it's entirely unrelated. For a binary format to be easily configurable puts a requirement up front for editing tools. Like, something that can read and write the format without being the daemon itself. But even ready availability of a high quality tool (and thus of some code maturity) already brings complexity.
You can't just fire up your favourite editor to whip up a config. You have to fiddle with commands and stick them in batchfiles. If the tools are even amendable to that (how long did i
Re: (Score:3)
The improvement is unrelated to text vs binaries. It's related to centralisation. Providing the binaries are openly defined and easily configurable that is just a distraction from the core issue: the system should be resistant to breakage and easier to manage, not more difficult.
The problem is that some things require complexity.
You can't have a configurator that lets you toy around with packaged configurations come up with every possible permutation you may need.
So what you get is a binary that is constantly in flux to add whatever person X's need for it is. Person X having wasted 85 hours out of his life ripping your configurator out of the system so that he could manage things directly.
So, to the contrary, I think your way of thinking is the problem.
The assumption that yo
Re: (Score:2)
The assumption that your binary can do everything, or that people shouldn't want to do anything else is hubris.
The alternative is literally a bunch of text files. Yes, a binary can do everything, it has that power. That's not hubris, that's fact. Hubris would come into play if I said this is somehow trivial. I made no such claim, the solution would be complex to design, but doesn't necessarily need to be complex to administer (that's is what my complexity of the windows registry was referring to, the general way that configurations are stored in it and the garbage tool we use to manipulate it).
Do you know what the #1 request is? How to get the old network configuration scripts back, because like nmcli will never be able to replace a script.
And binaries aren't th
Why does it matter? (Score:1)
I'm the author of the project. The format that I chose for system76-scheduler shouldn't matter to anyone. system76-scheduler is the only consumer of its own configuration files. The whole point of choosing RON is because it can succinctly express maps with arrays better than TOML and JSON. Implementation-wise it's just importing serde, adding attributes to your config struct, and typing `ron::from_str(&buffer)` to deserialize the buffered file.
{ -5: [ "high-priority-task" ], 5: [ "low-priority-task"]
Give it up (Score:2)
It will never be The Year of Linux On The Desktop.
Sorry.
Re: (Score:2)
Sorry you didn't get the memo.
Re: (Score:2)
Year of Linux On The Desktop came for me back in ~2007.
I was off and on between 1993 and 1999,which is when I couldn't stand Windows as a desktop anymore. It was horrendously pathetic, and I realized that nothing was going to make it better. I had just gotten my last Windows virus, which wiped out everything I had done for the last five years. I had no backups since I was a college student without money for such luxuries, so I was starting from scratch again. Might as well start over by replacing Windows with Linux.
Even with all its quirks, Linux treated me ver
Re: (Score:2)
Out of the box, Kubuntu needs some tweaking to not suck:
1) Ditch KDEPIM like the plague it is. Replace it with something else (I chose Thunderbird and Lightning).
2) Configure Konqueror as the file manager, as Dolphin sucks, Sucks, SUcks, SUCks, SUCKs, SUCKS, SUCKS!
That's pretty much all.
Despite all that, I have come to the conclusion that the KDE devs are actively trying to destroy KDE from the inside. The catastrophe that is Nepomuk (and the whole fantastically ill-conceived semantic desktop) was the first salvo (which is what destroyed KDEPIM), followed by the monumentally brain-damaged decision to replace the stellar Konqueror with the minimally functional, almost entirely useless, Dolphin. Then, they started systematically removing Konqueror's most useful features in an attempt to drag it down to Dolphin's level.
And in spite of all that, it's STILL heads and shoulders better than Windows for me
and there it is.
If you spend half your life Tweaking, Replacing and Configuring, you can sorta-kinda get Linux to "not suck".
Life's too short for that, thanks!
So, please believe me that I am really not Trolling when I ask: Why not OS X/macOS? It just seems like a no-brainer for people who are sick to death with Windows (which, having used and admin-ed it in every single Dev. and other job for 4 decades, I am well familiar with!); but want to work with their computer, rather than work on their computer.
So wh
Re: (Score:2)
Nobody mentioned that until you, moron.
This is an interesting and potentially positive move for those of us who do use System 76 devices or run Pop_OS! on other devices. No-one is suggesting that Linux will take over the desktop as a result.
Well, since mine was only about the third comment to the article, I was hardly appropriating a well-established conversational-thread.
Moron.
And, because it was patently obvious that re-prioritizing the UI is intended to make the system more responsive to the User (rather than more efficient at non-user-facing tasks), the intended result was to make Linux more palatable to use for "Desktop" Applications.
Moron.
Sounds Reasonable (Score:5, Interesting)
As a desktop Linux user and a professor who is right now teaching scheduling to my Operating System class, this sounds really reasonable. The fact of the matter is that the desktop seems to still periodically become unresponsive in situations where it seems like it shouldn't. And part of the blame may fall on trusting CFS too much. Any modern scheduler is making guesses about what to prioritize based on process behavior. But, honestly, in many cases, we know what we want to prioritize for a responsive desktop environment, so why not build something which tells it?
Also, being in a situation where I taught the CFS algorithm in an Operating Systems course, I did a bunch of reading about it. I found that there were a lot of conflicting descriptions of how it works. I wound up having to go read the source code to be sure, and what I found is that a lot of the descriptions of how it works are inaccurate. Usually when we talk about modern desktop and server schedulers, we say that they're trying to prioritize I/O-bound processes and deprioritize CPU-bound processes. And a lot of the descriptions of CFS says that it does this because threads which are using the CPU have a charge against their vruntime, but threads which are waiting do not. But this turns out not to be necessarily true, as threads which enter an I/O wait are actually effectively removed from the queue and then later reinserted. And due to how the math works, if all the other I/O-bound threads on a given core are in an I/O wait state, they'll wind up with the same vruntime as a CPU-bound thread (or worse in some cases). Once you add in process groups and moving between cores, it's complex enough that it's hard to reason about exactly what happens on average without collecting some real data, but there's no clear reason to believe (at least not from looking at the code) that threads which do user interaction will automatically get any priority. So having a process which adjusts the priority numbers instead sounds like a very reasonable idea to me.
Re: (Score:3)
System76 sells Linux laptops. They're in the business of making the desktop experience on their laptops not suck ass.
I don't really care why they chose Rust, but they're doing all their current work in Rust, and that's their choice. All I know is that their desktop keeps getting better and better.
Re: (Score:2)
Their argument is that this work somehow represents a propaganda piece for Rust. A programming language.
System76 is in the business of selling Linux laptops. This work is to make their product not suck.
Only one person gives a shit what language it's written in- the author of the post I replied to.
If you can't see that, you're as blinded your political beliefs as they are.
Re: (Score:2)
I invite you to show this.
I literally did. Pretending I didn't doesn't do your position any good.
Not just any programming language. A programming language with a Mission. Several, in fact. To replace C, especially in "systems programming". To do away with out-of-bounds accesses and some other types of errors. To enforce "niceness" in the community, hence CoC.
Not relevant.
Your dislike of Rust simply isn't relevant. It's the tool they used to do the job they needed to do, which was not to promote Rust.
Announcing you did done a program that does something useful is one thing. Loudly announcing that the most important thing about the program you just did done and gone wrote is this specific programming language is something else. That's ment to bring the programming language's Mission to the fore.
They did no such thing. It just feels that way to you because you get triggered if someone does something in Rust.
That's what you assume, but did not show. In fact, you said you neither knew nor cared why they did do this and why they picked that language to do it.
What the fuck are you talking about?
Your assertion is that their distribution, which is custom tailored to run on the laptops that they manufacture, is actually a vessel for which t
Re: (Score:2)
No, you claimed something. You didn't show it. There is a difference.
Wrong answer.
Actually, it is. You asserted it was "[just] a programming language", and I say that's not all there is to it.
You're attempting to impose guilt by association. It is just a programming language. Anything else about that language is not relevant in the context of this argument. ReiserFS was written by a convicted murderer. Those who use it are not complicit in that murder.
You don't like CoCs, and thus anyone who uses Rust is complicit in the tyranny of the wokers. We get it. Be more fucking transparent.
Arguing in bad-faith to score points against your arch nemesis, the CoC, is fucking pathetic.
Re: (Score:2)
This a quiz? If that's all you got, we're done here.
And yet you continue.
That's not how "guilt by association" works.
You keep combining words into sentences, but they don't have any fucking bearing on reality.
You're attempting to twist everyone else's reality into your political viewpoint on Rust.
Yes, that is how guilt by association works.
I don't agree with you there, nor does the rust community by its own admission.
That's because you're fallaciously ascribing guilt to them, via association with the language Rust.
System76's Press Release didn't even include the word Rust. Their github is full of a shit-ton of code, a tiny minority of which, is Rust.
Nobody implied so. The two acts are not connected.
You're right. Nobody impl
Re: (Score:2)
"Propaganda Effort"? (Score:1)
The main selling point of this thing isn't "improving responsiveness" but "promoting rust", complete with "promoting a rust-branded data format". Reasons for concluding this and reasons motivating the perpetrators left as an exercise. But it is safe to say that this is a propaganda-effort.
I'm the author of system76-scheduler. Before you accuse projects of Rust propaganda, try reading the README of the project you're accusing. There's no mention of Rust in the README outside of the fact that I detailed the format of its configuration files as "Rusty Object Notation". It's completely reasonable for me to declare the formatting of its configuration file. Regardless, it would also be perfectly normal for a project's own README to mention what language it is written in. C++, Java, and Python proj
Re: (Score:2)
Spot on. Linux on desktop still regularly freezes completely, for minutes in a row, sometimes tens of minutes, while the CPU is on 100% doing nothing but seemingly pointless disk I/O. I do not know what amateurs programmed that shit, but they should hang themselves out of pure shame.
A desktop OS scheduler has one top priority that should never, NEVER, EVER be broken: allow instant responsiveness to user input, 100% of the time, forever.
If no normal scheduler can achieve that, then even reserving every sec
Re: (Score:2)
> freezes completely, for minutes in a row, sometimes tens of minutes, while the CPU is on 100% doing nothing but seemingly pointless disk I/O
Hey, when my NFS server reboots I WANTED to not be able to type for half an hour.
Oh, no, wait, that's insane.
I only have a 4GHz Ryzen with 32GB here, but it still stalls on typing input for dozens of seconds in many apps, which a Mac Plus with 1MB RAM and an 8MHz 68000 never did. Because nobody would find that acceptable.
I remember both OS/2 in 1992 and BeOS in 19
Re: (Score:2)
There's also some tweaks around sound and media processing, but I cannot find the articles.
Re: Good luck with that (Score:2)
Also the work performed by this daemon doesn't necessarily have to be that performant just because it's too do with performance. As I read it, it sits there informing the kernel about process priority. Those priorities probably don't change very often.
Finally (Score:2)
"making a trade-off from the default CFS to benefit Desktop configurations over the typical load a server might see"
That's only a decade or two late. Too bad that insane Linus keeps blocking proper desktop scheduling and with that keeps blocking Linux desktop advance.