![]() | |||||||||||||
Messages in this thread |
On Fri, 04 Jul 2008 08:50:47 +0530 Balbir Singh <balbir@linux.vnet.ibm.com> wrote: > > I was referring to the below (which is where the conversation ended). > > > > It questions the basis of the whole feature. > > > > In the email below, I referred to Hugh's comment on tracking total_vm as a more > achievable target and it gives a rough approximation of something worth > limiting. I agree with him on those points and mentioned my motivation for the > memrlimit patchset. We also look forward to enhancing memrlimit to control > mlock'ed pages (as it provides the generic infrastructure to control RLIMIT'ed > resources). Given Hugh's comment, I looked at it from the more positive side > rather the pessimistic angle. I've had discussions along these lines with Paul > Menage and Kamezawa. In the past we've discussed and there are cases where > memrlimit is not useful (large VM allocations with sparse usage), but there are > cases as mentioned below in the motivation for memrlimits as to why and where > they are useful. > > If there are suggestions to help improve the feature or provide similar > functionality without the noise; I am all ears Well I've never reeeeeeealy understood what the whole feature is for. +Advantages of providing this feature + +1. Control over virtual address space allows for a cgroup to fail gracefully + i.e., via a malloc or mmap failure as compared to OOM kill when no + pages can be reclaimed. +2. It provides better control over how many pages can be swapped out when + the cgroup goes over its limit. A badly setup cgroup can cause excessive + swapping. Providing control over the address space allocations ensures + that the system administrator has control over the total swapping that + can take place. umm, OK. I'm not sure _why_ someone would want to do that. Perhaps some use-cases would help motivate us. Perhaps desriptions of real-world operational problems would would be improved or solved were this feature available to the operator. | ||||||||||||
| Last update: 2008-07-04 06:29 [W:0.150 / U:2.580 seconds] ©2003-2008 Jasper Spaans | |||||||||||||