On Tue, Jun 14, 2016 at 03:47:20PM +0000, Topi Miettinen wrote: > On 06/14/16 07:01, Michal Hocko wrote: > > On Mon 13-06-16 22:44:10, Topi Miettinen wrote: > >> Present maximum used memory in cgroup memory.current_max. > > > > It would be really much more preferable to present the usecase in the > > patch description. It is true that this information is presented in the > > v1 API but the current policy is to export new knobs only when there is > > a reasonable usecase for it. > > > > This was stated in the cover letter: > https://lkml.org/lkml/2016/6/13/857 > > "There are many basic ways to control processes, including capabilities, > cgroups and resource limits. However, there are far fewer ways to find out > useful values for the limits, except blind trial and error. > > This patch series attempts to fix that by giving at least a nice starting > point from the actual maximum values. I looked where each limit is checked > and added a call to limit bump nearby." > > "Cgroups > [RFC 02/18] cgroup_pids: track maximum pids > [RFC 03/18] memcontrol: present maximum used memory also for > [RFC 04/18] device_cgroup: track and present accessed devices > > For tasks and memory cgroup limits the situation is somewhat better as the > current tasks and memory status can be easily seen with ps(1). However, any > transient tasks or temporary higher memory use might slip from the view. > Device use may be seen with advanced MAC tools, like TOMOYO, but there is no > universal method. Program sources typically give no useful indication about > memory use or how many tasks there could be." > > I can add some of this to the commit message, is that sufficient for you? It's useful to have a short summary of the justification in each patch as well. Other than that it's fine to be broader and more detailed about your motivation in the coverletter. I didn't catch the coverletter, though. It makes sense to CC recipients of any of those patches on the full series, including the cover, since even though we are specialized in certain areas of the code, many of us are interested in the whole picture of addressing a problem, and not just the few bits in our area without more context. As far as the memcg part of this series goes, one concern is that page cache is trimmed back only when there is pressure, so in all but very few cases the high watermark you are introducing will be pegged to the configured limit. It doesn't give a whole lot of insight. But there are consumers that are less/not compressible than cache, such as anonymous memory, unreclaimable slab, maybe socket buffers etc. Having spikes in those slip through two sampling points is an issue, indeed. Adding consumer-specific watermarks might be useful. Thanks -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>