On Tue, 2015-05-19 at 17:15 +0200, Michal Hocko wrote: > [Let's CC Ben here - the email thread has started here: > http://marc.info/?l=linux-mm&m=143203206402073&w=2 and it seems Debian > is disabling memcg controller already so this might be of your interest] > > On Tue 19-05-15 15:43:45, Mel Gorman wrote: > [...] > > After I wrote the patch, I spotted that Debian apparently already > > does something like this and by coincidence they matched the > > parameter name and values. See the memory controller instructions on > > https://wiki.debian.org/LXC#Prepare_the_host . So in this case at least > > upstream would match something that at least one distro in the field > > already uses. > > I've read through > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534964 and it seems > that the primary motivation for the runtime disabling was the _memory_ > overhead of the struct page_cgroup > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534964#152). This is > no longer the case since 1306a85aed3e ("mm: embed the memcg pointer > directly into struct page") merged in 3.19. > > I can see some point in disabling the memcg due to runtime overhead. I was also concerned about runtime overhead. > There will always be some, albeit hard to notice. If an user really need > this to happen there is a command line option for that. The question is > who would do CONFIG_MEMCG && !MEMCG_DEFAULT_ENABLED. Do you expect any > distributions go that way? > Ben, would you welcome such a change upstream or is there a reason to > change the Debian kernel runtime default now that the memory overhead is > mostly gone (for 3.19+ kernels of course)? I have been meaning to reevaluate this as I know the overhead has been reduced. Given Mel's benchmark results, I favour keeping it disabled by default in Debian. So I would welcome this change. Ben. -- Ben Hutchings I'm not a reverse psychological virus. Please don't copy me into your sig.
Attachment:
signature.asc
Description: This is a digitally signed message part