Hi,
GNOME and KDE developers are working on resource control to help improve interactivity and system responsiveness when under pressure. This is done by isolating three resources: cpu, memory, and io, and setting either limits, or more typical is to set minimum resources on the high priority processes.
Resource control demo, this is a bit more desktop oriented https://github.com/facebookexperimental/resctl-demo
Resource Control (2019) Dan Schatzberg, this is a bit more server oriented https://www.youtube.com/watch?v=30i7SamZxRU
Also related to this effort is having a user space oom killer. The kernel's built-in oomkiller is primarily concerned about keeping the kernel itself safely running. It's not concerned about user space responding predictably or optimally.
Much of the above work is predicated on oomd2 There's been significant work lately integrating portions of it into systemd as systemd-oomd. The idea is to intelligently determine what processes are taking up way more resources than is reasonable (i.e. they're likely misbehaving) and kill them off so that other processes survive and the system doesn't completely faceplant, which would require either human intervention or worse case, force reboot.
What things are high priority for a server or cloud use cases, aren't the same as for desktops. So while all the concepts are the same, I expect Server WG folks will want to take a look at optimizing for typical server workloads.
Hi Chris,
I think another area to look at is going to be DVFS and thermal throttling. A lot of systems out there today have /very/ poor thermal management and will (under load) start doing nasty things to avoid melting. The user experience is *awful* when this happens. More proactive handling using e.g. CPPC platform extensions for collaboration between the platform and the OS would allow the OS to know ahead of time that a thermal event is coming and reduce the load proactively. Nobody really does this today (although I'm certain Apple does in their own silicon because it's an obvious innovation), but there are a few projects headed there in Linux.
Jon.
On Mon, Dec 21, 2020 at 3:03 AM Chris Murphy lists@colorremedies.com wrote:
Hi,
GNOME and KDE developers are working on resource control to help improve interactivity and system responsiveness when under pressure. This is done by isolating three resources: cpu, memory, and io, and setting either limits, or more typical is to set minimum resources on the high priority processes.
Resource control demo, this is a bit more desktop oriented https://github.com/facebookexperimental/resctl-demo
Resource Control (2019) Dan Schatzberg, this is a bit more server oriented https://www.youtube.com/watch?v=30i7SamZxRU
Also related to this effort is having a user space oom killer. The kernel's built-in oomkiller is primarily concerned about keeping the kernel itself safely running. It's not concerned about user space responding predictably or optimally.
Much of the above work is predicated on oomd2 There's been significant work lately integrating portions of it into systemd as systemd-oomd. The idea is to intelligently determine what processes are taking up way more resources than is reasonable (i.e. they're likely misbehaving) and kill them off so that other processes survive and the system doesn't completely faceplant, which would require either human intervention or worse case, force reboot.
What things are high priority for a server or cloud use cases, aren't the same as for desktops. So while all the concepts are the same, I expect Server WG folks will want to take a look at optimizing for typical server workloads.
-- Chris Murphy _______________________________________________ server mailing list -- server@lists.fedoraproject.org To unsubscribe send an email to server-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org
This should be of interest: https://fedoraproject.org/wiki/Changes/EnableSystemdOomd
There's some discussion of it in devel@; the Server Edition looks like it's a natural fit for having this enabled. It won't work with Kubernetes (which requires cgroupv1) but as I understand it that's not a common use case anyway for Fedora Server?
On Wed, Dec 30, 2020 at 3:08 PM Michel Alexandre Salim michel@michel-slm.name wrote:
This should be of interest: https://fedoraproject.org/wiki/Changes/EnableSystemdOomd
There's some discussion of it in devel@; the Server Edition looks like it's a natural fit for having this enabled. It won't work with Kubernetes (which requires cgroupv1) but as I understand it that's not a common use case anyway for Fedora Server?
Fedora Kubernetes should be able to move to CGroup v2 now that it and all the CRI options it supports all support cgroupv2. The kubernetes package just needs to be updated to 1.19+ (preferably 1.20+).
-- 真実はいつも一つ！/ Always, there's only one truth!
server@lists.fedoraproject.org
-
Chris Murphy -
Jon Masters -
Michel Alexandre Salim -
Neal Gompa