Re: Reserve resources for active users (Workstation) - Fedora 33 Self-Contained Change proposal
On Sun, 2020-07-12 at 07:18 +0900, Alexey A. wrote: > >oomd (or rather systemd-oomd) and will make heavy use of cgroups to > work well > > Other side of this is high CPU usage: > https://github.com/facebookincubator/oomd/issues/79 That is an implementation problem of oomd. And irrelevant in the context of systemd-oomd. Benjamin > сб, 11 июл. 2020 г. в 17:34, Benjamin Berg : > > On Sat, 2020-07-11 at 08:43 +0200, Igor Raits wrote: > > > On Fri, 2020-07-10 at 15:55 -0400, Ben Cotton wrote: > > > > > > https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS > > > > > > > > == Summary == > > > > This proposal adds cgroup based resource protections for the > > active > > > > graphical session. This is done by passing a memory protection > > of > > > > 250MiB to active users (capped at 10% of system memory) and by > > > > enabling other cgroup controllers (CPU, IO) to ensure important > > > > session processes get the resources they need. > > > > > > Just curious, why 250MiB and not some other number? > > > > Initially, it was an educated guess (i.e. it seemed low enough to > > be > > reasonable and high enough to be useful). > > > > I then continued to do a bit of experimentation and found that my > > gnome-shell would stop page-faulting quite a lot if I gave the > > session > > processes >=350MiB of memory (measured by manually setting > > memory.max > > and using "perf trace -F -p X"). > > > > Tejun suggests it is sufficient to protect around 50-75% of the > > required memory, so 250MiB still seemed like a reasonable value > > after > > those tests. > > > > Note that it is easy to change, simpliy modify /etc/uresourced.conf > > (and, ideally reboot to ensure it is properly applied to your user > > session). > > > > > > See: https://pagure.io/fedora-workstation/issue/154 > > > > > > > > == Owner == > > > > * Name: [[User:benzea|Benjamin Berg]] > > > > * Email: bb...@redhat.com > > > > * Product: Workstation > > > > * Responsible WG: Workstation > > > > > > > > > > > > == Detailed Description == > > > > Graphical sessions should always be responsive, even when the > > > > machine > > > > is doing a lot work or in the extreme case has started to > > thrash. > > > > We > > > > have started to ship EarlyOOM with F32, however, while it is a > > good > > > > solution to this date, it is shipped with the understanding of > > > > being > > > > superseded by other approaches in the future. > > > > > > Does it mean we do not ship earlyoom anymore or what is this > > sentence > > > supposed to indicate? > > > > EarlyOOM is still very useful today. However, from my point of > > view, > > EarlyOOM is just an intermediate measure until a more advanced > > solution > > is implemented and can be rolled out to users. This solution will > > be > > based on oomd (or rather systemd-oomd) and will make heavy use of > > cgroups to work well. > > > > This is a longer path, shipping uresourced puts us a step further > > down > > that road. > > > > > [SNIP] > > > > Benjamin > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Reserve resources for active users (Workstation) - Fedora 33 Self-Contained Change proposal
>oomd (or rather systemd-oomd) and will make heavy use of cgroups to work well Other side of this is high CPU usage: https://github.com/facebookincubator/oomd/issues/79 сб, 11 июл. 2020 г. в 17:34, Benjamin Berg : > On Sat, 2020-07-11 at 08:43 +0200, Igor Raits wrote: > > On Fri, 2020-07-10 at 15:55 -0400, Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS > > > > > > == Summary == > > > This proposal adds cgroup based resource protections for the active > > > graphical session. This is done by passing a memory protection of > > > 250MiB to active users (capped at 10% of system memory) and by > > > enabling other cgroup controllers (CPU, IO) to ensure important > > > session processes get the resources they need. > > > > Just curious, why 250MiB and not some other number? > > Initially, it was an educated guess (i.e. it seemed low enough to be > reasonable and high enough to be useful). > > I then continued to do a bit of experimentation and found that my > gnome-shell would stop page-faulting quite a lot if I gave the session > processes >=350MiB of memory (measured by manually setting memory.max > and using "perf trace -F -p X"). > > Tejun suggests it is sufficient to protect around 50-75% of the > required memory, so 250MiB still seemed like a reasonable value after > those tests. > > Note that it is easy to change, simpliy modify /etc/uresourced.conf > (and, ideally reboot to ensure it is properly applied to your user > session). > > > > See: https://pagure.io/fedora-workstation/issue/154 > > > > > > == Owner == > > > * Name: [[User:benzea|Benjamin Berg]] > > > * Email: bb...@redhat.com > > > * Product: Workstation > > > * Responsible WG: Workstation > > > > > > > > > == Detailed Description == > > > Graphical sessions should always be responsive, even when the > > > machine > > > is doing a lot work or in the extreme case has started to thrash. > > > We > > > have started to ship EarlyOOM with F32, however, while it is a good > > > solution to this date, it is shipped with the understanding of > > > being > > > superseded by other approaches in the future. > > > > Does it mean we do not ship earlyoom anymore or what is this sentence > > supposed to indicate? > > EarlyOOM is still very useful today. However, from my point of view, > EarlyOOM is just an intermediate measure until a more advanced solution > is implemented and can be rolled out to users. This solution will be > based on oomd (or rather systemd-oomd) and will make heavy use of > cgroups to work well. > > This is a longer path, shipping uresourced puts us a step further down > that road. > > > [SNIP] > > Benjamin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Reserve resources for active users (Workstation) - Fedora 33 Self-Contained Change proposal
On Sat, 2020-07-11 at 07:33 -0500, Michael Catanzaro wrote: > On Sat, Jul 11, 2020 at 2:28 pm, Igor Raits > wrote: > > My question was more targeted whether we are not going to ship anymore > > earlyoom by default with this change or will they be both shipped at > > thie moment until something better is ready? > > We'll continue to ship earlyoom for the foreseeable future as we > continue to watch progress on systemd-oomd: > > https://github.com/systemd/systemd/pull/15206 Yup, exactly that. This change has some overlap with EarlyOOM, but neither mechanism is complete on its own, and it makes sense for both of them to coexist. So, EarlyOOM protects the system by killing processes when the system thrashes, or if heuristics suggest it may be close to thrashing. uresourced on the other hand approaches the problem from the other side. It does not prevent trashing at all, but instead tries to shield certain processes (i.e. the graphical session) from the worst effects. Benjamin signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Reserve resources for active users (Workstation) - Fedora 33 Self-Contained Change proposal
On Sat, Jul 11, 2020 at 2:28 pm, Igor Raits wrote: My question was more targeted whether we are not going to ship anymore earlyoom by default with this change or will they be both shipped at thie moment until something better is ready? We'll continue to ship earlyoom for the foreseeable future as we continue to watch progress on systemd-oomd: https://github.com/systemd/systemd/pull/15206 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Reserve resources for active users (Workstation) - Fedora 33 Self-Contained Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 2020-07-11 at 10:33 +0200, Benjamin Berg wrote: > On Sat, 2020-07-11 at 08:43 +0200, Igor Raits wrote: > > On Fri, 2020-07-10 at 15:55 -0400, Ben Cotton wrote: > > > > > > https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS > > > > > > == Summary == > > > This proposal adds cgroup based resource protections for the > > > active > > > graphical session. This is done by passing a memory protection of > > > 250MiB to active users (capped at 10% of system memory) and by > > > enabling other cgroup controllers (CPU, IO) to ensure important > > > session processes get the resources they need. > > > > Just curious, why 250MiB and not some other number? > > Initially, it was an educated guess (i.e. it seemed low enough to be > reasonable and high enough to be useful). > > I then continued to do a bit of experimentation and found that my > gnome-shell would stop page-faulting quite a lot if I gave the > session > processes >=350MiB of memory (measured by manually setting memory.max > and using "perf trace -F -p X"). > > Tejun suggests it is sufficient to protect around 50-75% of the > required memory, so 250MiB still seemed like a reasonable value after > those tests. > > Note that it is easy to change, simpliy modify /etc/uresourced.conf > (and, ideally reboot to ensure it is properly applied to your user > session). Thanks for detailed answer! > > > See: https://pagure.io/fedora-workstation/issue/154 > > > > > > == Owner == > > > * Name: [[User:benzea|Benjamin Berg]] > > > * Email: bb...@redhat.com > > > * Product: Workstation > > > * Responsible WG: Workstation > > > > > > > > > == Detailed Description == > > > Graphical sessions should always be responsive, even when the > > > machine > > > is doing a lot work or in the extreme case has started to thrash. > > > We > > > have started to ship EarlyOOM with F32, however, while it is a > > > good > > > solution to this date, it is shipped with the understanding of > > > being > > > superseded by other approaches in the future. > > > > Does it mean we do not ship earlyoom anymore or what is this > > sentence > > supposed to indicate? > > EarlyOOM is still very useful today. However, from my point of view, > EarlyOOM is just an intermediate measure until a more advanced > solution > is implemented and can be rolled out to users. This solution will be > based on oomd (or rather systemd-oomd) and will make heavy use of > cgroups to work well. My question was more targeted whether we are not going to ship anymore earlyoom by default with this change or will they be both shipped at thie moment until something better is ready? > This is a longer path, shipping uresourced puts us a step further > down > that road. > > > [SNIP] > > Benjamin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8JsGwACgkQEV1auJxc Hh4eYQ/9Fmqs5eP9swk+JlsIwS/KiUzx2IkPDeIsdu0bGdLFpm6/ElRtEWLQMAnP vHEX35MUNWwbnphNTMsFUqWUDQ7UyfaBRak8CPpggkNCCiDERJniyx9TEWaV6X9O cNdCDo5opOgfmjOf5Sn71ucf3Hg0IePE3W9BiwHne7CAqkXrPmouYa95GD6T/gFE WCbQIqPTFFYgU9igaU5gUcOLJS/TwJe9ABB8tH+gfolPBG+c+UaR1BepGJH8+9e8 3ixjEedcA4Hh5iLPxpPX5nmw91L81kENhLGWhWWAa8TbkImLQ2SC+Phb57lll3PW 0IaJuRMvTV/rD4fMqWpKgdwNHwIe3dqzAvjF1gsYjmPHaY0dFRcxYBI/E0WLna2q /IYEzehUDbFZggPN8L+y4s5xywDq6xvbHLCemrSwzW7zB7Q6cfgQkUUUk/MntAwQ PvcV5Mb5eQqia4aMMUPbtgnuhU56AiQoA95MNpH+xVTyMqcOUUlci73x0rcbNc1P B2QPydWeUaK6chsO5LIDnPhcRkf874MRMZfRgYfuEUSNRl8fa0bOPGYajjOu28hV tJXiXviWQNa2rJLhey3CJCbTRWyestLZCmR6oXcU2vX1EniNh9f7lvpjt4KxZ9pe L33Bj0znhpBg5YDni4bFgG+1eKQqSXS1E45dlqzg6XdfE/3noeU= =yzFL -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Reserve resources for active users (Workstation) - Fedora 33 Self-Contained Change proposal
On Sat, 2020-07-11 at 08:43 +0200, Igor Raits wrote: > On Fri, 2020-07-10 at 15:55 -0400, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS > > > > == Summary == > > This proposal adds cgroup based resource protections for the active > > graphical session. This is done by passing a memory protection of > > 250MiB to active users (capped at 10% of system memory) and by > > enabling other cgroup controllers (CPU, IO) to ensure important > > session processes get the resources they need. > > Just curious, why 250MiB and not some other number? Initially, it was an educated guess (i.e. it seemed low enough to be reasonable and high enough to be useful). I then continued to do a bit of experimentation and found that my gnome-shell would stop page-faulting quite a lot if I gave the session processes >=350MiB of memory (measured by manually setting memory.max and using "perf trace -F -p X"). Tejun suggests it is sufficient to protect around 50-75% of the required memory, so 250MiB still seemed like a reasonable value after those tests. Note that it is easy to change, simpliy modify /etc/uresourced.conf (and, ideally reboot to ensure it is properly applied to your user session). > > See: https://pagure.io/fedora-workstation/issue/154 > > > > == Owner == > > * Name: [[User:benzea|Benjamin Berg]] > > * Email: bb...@redhat.com > > * Product: Workstation > > * Responsible WG: Workstation > > > > > > == Detailed Description == > > Graphical sessions should always be responsive, even when the > > machine > > is doing a lot work or in the extreme case has started to thrash. > > We > > have started to ship EarlyOOM with F32, however, while it is a good > > solution to this date, it is shipped with the understanding of > > being > > superseded by other approaches in the future. > > Does it mean we do not ship earlyoom anymore or what is this sentence > supposed to indicate? EarlyOOM is still very useful today. However, from my point of view, EarlyOOM is just an intermediate measure until a more advanced solution is implemented and can be rolled out to users. This solution will be based on oomd (or rather systemd-oomd) and will make heavy use of cgroups to work well. This is a longer path, shipping uresourced puts us a step further down that road. > [SNIP] Benjamin signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Reserve resources for active users (Workstation) - Fedora 33 Self-Contained Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-07-10 at 15:55 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS > > == Summary == > This proposal adds cgroup based resource protections for the active > graphical session. This is done by passing a memory protection of > 250MiB to active users (capped at 10% of system memory) and by > enabling other cgroup controllers (CPU, IO) to ensure important > session processes get the resources they need. Just curious, why 250MiB and not some other number? > See: https://pagure.io/fedora-workstation/issue/154 > > == Owner == > * Name: [[User:benzea|Benjamin Berg]] > * Email: bb...@redhat.com > * Product: Workstation > * Responsible WG: Workstation > > > == Detailed Description == > Graphical sessions should always be responsive, even when the machine > is doing a lot work or in the extreme case has started to thrash. We > have started to ship EarlyOOM with F32, however, while it is a good > solution to this date, it is shipped with the understanding of being > superseded by other approaches in the future. Does it mean we do not ship earlyoom anymore or what is this sentence supposed to indicate? > With `uresourced` a small daemon was written that enables protection > of the graphical user session. It serves the following main purposes: > > * Safely modify existing GNOME systemd units to closer adhere to > https://systemd.io/DESKTOP_ENVIRONMENTS/ (until this is merged > upstream). > * Enables the CPU and IO cgroup controllers for users to prevent e.g. > fork bombs from taking over the system. > * Allocates a memory guarantee for any *active* user which is > distributed to core session processes. > > Precautions are in place to not negatively affect systems: > > * Active users will receive a protected memory allocation of 250MiB > allocation, but capped at 10% of system memory. So low memory systems > should not be negatively impacted. Said differently, the memory > subsystem treats the core session processes in comparison to > everything else as if they were using 250MiB less than they actually > are. > * `uresourced` detects whether the user session is using systemd to > prevent passing memory guarantees to processes that are not important > (e.g. not a GNOME session). > * Enabling the IO controller has no effect on Fedora currently. > > NOTES: > > * `uresourced` is designed to be obsoleted. Everything it does should > be absorbed by other upstreams. However, it is a good and safe > solution that eases development and permits shipping the benefits to > users now. > * Enabling the cgroup controllers may slightly increase the > scheduling > overhead that the kernel imposes. I don't have numbers right now, but > expect this to be <=1% of overall system CPU time. > > > == Benefit to Fedora == > This change proposal will improve interactivity of graphical sessions > in certain situations. It also is an important step on the path to > reap the benefits of systemd and cgroups in workstation scenarios. > > == Scope == > * Proposal owners: > * Install `uresourced` on workstations by default > * Add a preset to enable `uresourced` by default > > * Other developers: no further changes are needed > > * Release engineering: [https://pagure.io/releng/issue/9592] > * Policies and guidelines: N/A (not needed) > * Trademark approval: N/A (not needed for this Change) > > > == Upgrade/compatibility impact == > No impact. The worst case scenario is that the feature will not be > enabled. > > == How To Test == > Testing this has multiple aspects. From the technical side, a test is > as simple as: > > * Install and enable `uresourced` > * Reboot (to make absolutely sure the user session has picked up all > changes, logout may *not* be sufficient) > * Check values in `/sys/fs/cgroup/user.slice/memory.low`, > `/sys/fs/cgroup/user.slice/user-1000.slice/memory.low`, > `/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/memory.l > ow` > and > `/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/session. > slice/memory.low` > (should usually be 250MiB with the default configuration). > * Verify that the allocation is zero if the user is not active on any > seat (e.g. switch to GDM and log in via SSH or by doing a `sleep 10; > cat ...` and coming back). > * Check enabled controllers in > `/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/cgroup.c > ontrollers` > (should be `cpu io memory pids`). > > Beyond that, a test can be done to show that the cgroup kernel > controllers are actually beneficial in various scenarios. Possible > examples are: > > * Running mprime > (http://www.mersenne.org/ftp_root/gimps/p95v298b6.linux64.tar.gz); > choose local stress test, repeat by selecting 15 NOTE: mcatanzaro > has reported a huge impact, with both the session remaining mostly > responsive and EarlyOOM not kicking in (this makes sense, as overall > memory pressure is much lower, i.e. t
Reserve resources for active users (Workstation) - Fedora 33 Self-Contained Change proposal
https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS == Summary == This proposal adds cgroup based resource protections for the active graphical session. This is done by passing a memory protection of 250MiB to active users (capped at 10% of system memory) and by enabling other cgroup controllers (CPU, IO) to ensure important session processes get the resources they need. See: https://pagure.io/fedora-workstation/issue/154 == Owner == * Name: [[User:benzea|Benjamin Berg]] * Email: bb...@redhat.com * Product: Workstation * Responsible WG: Workstation == Detailed Description == Graphical sessions should always be responsive, even when the machine is doing a lot work or in the extreme case has started to thrash. We have started to ship EarlyOOM with F32, however, while it is a good solution to this date, it is shipped with the understanding of being superseded by other approaches in the future. With `uresourced` a small daemon was written that enables protection of the graphical user session. It serves the following main purposes: * Safely modify existing GNOME systemd units to closer adhere to https://systemd.io/DESKTOP_ENVIRONMENTS/ (until this is merged upstream). * Enables the CPU and IO cgroup controllers for users to prevent e.g. fork bombs from taking over the system. * Allocates a memory guarantee for any *active* user which is distributed to core session processes. Precautions are in place to not negatively affect systems: * Active users will receive a protected memory allocation of 250MiB allocation, but capped at 10% of system memory. So low memory systems should not be negatively impacted. Said differently, the memory subsystem treats the core session processes in comparison to everything else as if they were using 250MiB less than they actually are. * `uresourced` detects whether the user session is using systemd to prevent passing memory guarantees to processes that are not important (e.g. not a GNOME session). * Enabling the IO controller has no effect on Fedora currently. NOTES: * `uresourced` is designed to be obsoleted. Everything it does should be absorbed by other upstreams. However, it is a good and safe solution that eases development and permits shipping the benefits to users now. * Enabling the cgroup controllers may slightly increase the scheduling overhead that the kernel imposes. I don't have numbers right now, but expect this to be <=1% of overall system CPU time. == Benefit to Fedora == This change proposal will improve interactivity of graphical sessions in certain situations. It also is an important step on the path to reap the benefits of systemd and cgroups in workstation scenarios. == Scope == * Proposal owners: * Install `uresourced` on workstations by default * Add a preset to enable `uresourced` by default * Other developers: no further changes are needed * Release engineering: [https://pagure.io/releng/issue/9592] * Policies and guidelines: N/A (not needed) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == No impact. The worst case scenario is that the feature will not be enabled. == How To Test == Testing this has multiple aspects. From the technical side, a test is as simple as: * Install and enable `uresourced` * Reboot (to make absolutely sure the user session has picked up all changes, logout may *not* be sufficient) * Check values in `/sys/fs/cgroup/user.slice/memory.low`, `/sys/fs/cgroup/user.slice/user-1000.slice/memory.low`, `/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/memory.low` and `/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/session.slice/memory.low` (should usually be 250MiB with the default configuration). * Verify that the allocation is zero if the user is not active on any seat (e.g. switch to GDM and log in via SSH or by doing a `sleep 10; cat ...` and coming back). * Check enabled controllers in `/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/cgroup.controllers` (should be `cpu io memory pids`). Beyond that, a test can be done to show that the cgroup kernel controllers are actually beneficial in various scenarios. Possible examples are: * Running mprime (http://www.mersenne.org/ftp_root/gimps/p95v298b6.linux64.tar.gz); choose local stress test, repeat by selecting 15 NOTE: mcatanzaro has reported a huge impact, with both the session remaining mostly responsive and EarlyOOM not kicking in (this makes sense, as overall memory pressure is much lower, i.e. the session is waiting on memory related IO less). The proposal owners have not been able to reproduce this corner case so far. * Log in two user A and B (same seat), run `stress-ng -c NCPUS` in both. Switch between them and look at `top` to verify that the active user gets a 5 times higher CPU share overall. == User Experience == See other sections. == Dependencies == There are no further dependencies. == Contingency Plan == * Contingency mechanism: Remove uresourced f
