Resource management for the desktop

Posted Aug 31, 2020 10:31 UTC (Mon) by riteshsarraf (subscriber, #11138)
Parent article: Resource management for the desktop

I am glad this problem has finally been acknowledged. For years, Linux Desktop Users have been complaining about the stall problem without any acknowledgement. This LWN article, though, re-describes all those problems, now. :-)

Couple years ago, we had ulatencyd

uresourced, by the description, sounds very similar to it. I hope it does get acknowledged, accepted and really fixes the problem.

At the end of day, a Linux Desktop User does not want to initiate 100 GiB of data copy, and run into a stall of the OS, because:
* The destination disk is rotational and slow
* Buffered I/O ate all the memory
* CPU cycles are all blocked waiting for the I/O confirmation from the slow usb rotational disk

It should be fine to demote/contain such potential processes/jobs/slices that can block operations. Reserving some resources for house-keeping isn't a bad idea. Bad is to run into this bottleneck where you are blocked waiting for something and you can't process the wait quick because you have resource contention.

Resource management for the desktop

Posted Sep 1, 2020 13:52 UTC (Tue) by benzea (subscriber, #96937) [Link] (2 responses)

Oh, I didn't know about ulatencyd.

Seems like it still had to fight with the problem that we are not using systemd and were not placing applications and services into a cgroup hierarchy. Luckily this has improved a lot recently.

A quick scan also suggests t hat ulatencyd was modifying a number of IO scheduler settings. I wonder if anyone has an opinion on modifying IO scheduler settings. So far, my hope is that we can simply rely on cgroup based IO scheduling (io.weight) instead. But, I fear we need at least https://github.com/systemd/systemd/issues/16403 fixed before users will start seeing benefits.

Resource management for the desktop

Posted Sep 7, 2020 14:48 UTC (Mon) by riteshsarraf (subscriber, #11138) [Link]

I think ulatencyd was ahead of its time then. cgroups was fairly new and utilizing it in the desktop use case, then, was quite early.

I also remember how I used to try to contain resources to my Digikam instance, which back then was a memory hog, by simply scripting to run it under cgroup and allocating it a finite amount of resource so that it wouldn't bring the entire system down.

But that was all in 2015. Fast forward now, 2020, and I'm really very excited about this project of yours'. I hope it succeeds and becomes the single standard. We've already wasted enough of time.

This whole framework, when knit together, hopefully will solve us many many problems. Resource hogs, Memory leaking application, Power unfriendly ones; this could solve most of the usual desktop/laptop problems Linux users have.

Resource management for the desktop

Posted Sep 7, 2020 14:57 UTC (Mon) by riteshsarraf (subscriber, #11138) [Link]

As a longer term goal for the project, it'd also be nice to have process monitor. The world will never be perfect. There'll always be ill behaving applications. There'll always be web browsers, running heavy web pages, that are power hungry.

It'd be nice for uresourced to also have a monitoring feature in its roadmap. Something like this tool, should be there to monitor power hungry resources, and register events. How you want to process and present such events is a personalized decision, a policy or a mix of many such things; which could be left to DEs (KDE, GNOME) and distros (Fedora, Debian) to decide.

But we surely need a good monitor, to pop-up a notification about ill-behaving browser processes, which are draining the battery to half. I still get frustrated to know that a file indexing application in background, drained all the battery.