On 26.02.2015 20:53, Serge Hallyn wrote: > I've opened https://github.com/lxc/lxc/issues/453 . > I may implement it at some point, but it should be a pretty easy one so > I'm going to see if someone else is interested in doing so.
Serge, i'm very sorry for my bad English, but i wasn't able work out the core point: The order changes if the limits will grow by your values. Therefore, the "right" order in a config file is only valid for lxc-start, where the actual values are "unlimited" (max-int). If one will adjust during runtime (e.g. by lxc-cgroup), this order will hold, if the desired values are more low, but will fail, if the intention is to rise the amount of memory. And it's a challenge to understand this for every end user, i think. I'm using the memory controller with the "freeze on OOM" feature because i want to know who is responsible for the situation. To unlock this, one have to grant (temporary or long term) more memory to the container. I have a script that will re-configure such "runtime settings" for memory and the cpuset from the config files. A simple algorithm that will don't break the "rise limits" case: after parsing all the config (and includes) * "try" to set both, mem and memswap to the desired values, i.e. call the setters, but ignore errors. * simply do this again, but now pass errors. In case of "just an actual wrong order", the first "silent call" for mem will fail but will work after the silent call to memsw. In case of other problems like syntactical or semantical wrong values, the second calls will fail and offer an appropriate error message. Guido _______________________________________________ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
