[New: openFATE 316466] place default memory limit on processes within desktop session
Feature added by: Adam Spiers (aspiers) Feature #316466, revision 1 Title: place default memory limit on processes within desktop session Requested by: Adam Spiers (aspiers) Partner organization: openSUSE.org Description: It's currently possible for a memory leak in a userspace process to push a system far enough into swap that it basically results in the system being unusable for a significant amount of time. google-chrome, xfce4-panel, virt-manager, and nm-applet are a few recent examples which spring to mind. When kswapd is heavily stressed, logging in to the box to run top and kill some processes can take minutes or longer in the worst case. Maybe this could be argued to be a kernel bug, but ultimately I guess any kind of heavy swapping is going to kill performance. So instead of *solely* depending on the kernel to behave perfectly in low memory situations, it seems sensible to have some sort of preventative measure which would defend against buggy userspace processes. Therefore I suggest that desktop sessions should be tuned via cgroups to impose a default memory limit (RSS? VSS? I'm not sure which is best) of something like 80% of available RAM for any normal process, and then offer some kind of whitelist mechanism for processes which are expected to require a large amount of RAM. The ideal UX would be that if a desktop process hits the limit, a dialog box would pop up in the same session saying "This process is requesting more than $x RAM. This could be required for a genuine reason, or could be due to a memory leak. Deny / Allow / Always Allow". I'm not sure whether cgroups supports a mechanism for triggering userspace events like this, but if there's some way to achieve that, it would be great! Business case (Partner benefit): openSUSE.org: This would help promote openSUSE as a robust, reliable distribution, and the cgroups suggestion sounds like a pretty high reward to effort ratio which turns technical capability into practical advantage. (The dialog idea would probably take a lot more effort.) -- openSUSE Feature: https://features.opensuse.org/316466
Feature changed by: Adam Spiers (aspiers) Feature #316466, revision 4 Title: place default memory limit on processes within desktop session Requested by: Adam Spiers (aspiers) Partner organization: openSUSE.org Description: It's currently possible for a memory leak in a userspace process to push a system far enough into swap that it basically results in the system being unusable for a significant amount of time. google-chrome, xfce4-panel, virt-manager, and nm-applet are a few recent examples which spring to mind. When kswapd is heavily stressed, logging in to the box to run top and kill some processes can take minutes or longer in the worst case. Maybe this could be argued to be a kernel bug, but ultimately I guess any kind of heavy swapping is going to kill performance. So instead of *solely* depending on the kernel to behave perfectly in low memory situations, it seems sensible to have some sort of preventative measure which would defend against buggy userspace processes. Therefore I suggest that desktop sessions should be tuned via cgroups to impose a default memory limit (RSS? VSS? I'm not sure which is best) of something like 80% of available RAM for any normal process, and then offer some kind of whitelist mechanism for processes which are expected to require a large amount of RAM. The ideal UX would be that if a desktop process hits the limit, a dialog box would pop up in the same session saying "This process is requesting more than $x RAM. This could be required for a genuine reason, or could be due to a memory leak. Deny / Allow / Always Allow". I'm not sure whether cgroups supports a mechanism for triggering userspace events like this, but if there's some way to achieve that, it would be great! Business case (Partner benefit): openSUSE.org: This would help promote openSUSE as a robust, reliable distribution, and the cgroups suggestion sounds like a pretty high reward to effort ratio which turns technical capability into practical advantage. (The dialog idea would probably take a lot more effort.) + Discussion: + #1: Adam Spiers (aspiers) (2013-09-05 14:52:51) + Possible approaches to implementation are currently being discussed in + this thread: https://mailman.suse.de/mailman/private/research/2013-September/004069.html + We should probably open this discussion up by moving to a public list ... -- openSUSE Feature: https://features.opensuse.org/316466
participants (1)
-
fate_noreply＠suse.de