Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
system-helper: set IO class to idle #2071
Our benchmarks show this significantly reduces the interactivity impact of
Thanks to @wjt for the benchmarking. Copy/pasting his results:
Would there be a way for the install process itself to say whether it's interactive or not?
I could see gnome-software wanting to change the class of the I/O at runtime, for example, starting with the non-idle class when somebody clicks on the "Install" button in the UI, and switching it to idle when the app goes unfocused, or the user switches to another page.
If that's implementable, I'll file a separate issue.
@hadess It would be possible indeed, per the code in GNOME Software a process is at liberty to demote its own IO priority should it wish. We thought about this in Endless and weren't sure that the complexity of propagating interactivity through the ops in G-S, tracking the idle / normal threads in the pool (or having two pools), then tracking the same across D-Bus etc was worthwhile. Unless your system is already under IO load from a competing background process, setting the app installs/upgrades to idle prority isn't going to be that big a deal - Flatpak / OSTree operations are so catastrophically slow (because sync() is such a blunt instrument) that I didn't expect anyone to perform them interactively anyway. :P
There is much more low-hanging fruit to speed up the process - eg half the amount of IO we do (see ostreedev/ostree#1723), bunch transactions together across the system helper API so that triggers are only run once at the end of a batch of operations, etc. (Not sure if GNOME Software does or doesn't batch the ops together in one transaction in an upgrade run, but that is lost when the transaction meets the system helper woodchipper...)