I wrote a simple patch that allows to define per-UID virtual memory overcommit handling.
Configuration is stored in a hash list in kernel space reachable through /proc/overcommit_uid (surely there're better ways to do it, i.e. via configfs).
Since most of the time we've readers, the concurrent read/write accesses of the hash list are synchronized using the RCU (Read Copy Update) mutual exclusion.
Hash elements are defined using a triple:
The overcommit_* values have the same semantic of their respective sysctl variables. If a user is not present in the hash, the default system policy will be used (defined by /proc/sys/vm/overcommit_memory and /proc/sys/vm/overcommit_ratio).
- admin can allocate full memory + swap:
root@host # echo 0:2:100 > /proc/overcommit_uid
- processes belonging to sshd (uid=100) and ntp (uid=102) users can be quite critical, so use the same policy of the admin:
root@host # echo 100:2:100 > /proc/overcommit_uid
root@host # echo 102:2:100 > /proc/overcommit_uid
- Others can allocate up to the swap + 60% of the available RAM:
root@host # echo 2 > /proc/sys/vm/overcommit_memory && echo 60 > /proc/sys/vm/overcommit_ratio
The result in the example above is that the memory is never overcommitted (due to the value 2 in overcommit_memory) and the 40% of the RAM is used as spare memory, reserved for root processes and critical services only. Normal users can use only the 60% of the RAM. So, in conclusions, non-privileged users never hog the machine.
You can play with per-user overcommit parameters to implement your own VM allocation rules.
This is only a very simple approach to user resource management. If you want a more flexible, complete and powerful approach look at the containers work, a very interesting project actively developed in Linux.