linux-kernel - Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 4 May 2012 10:24:20 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Hiroyuki Kamezawa <kamezawa.hiroyuki@...il.com>
Cc:	David Rientjes <rientjes@...gle.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Randy Dunlap <rdunlap@...otime.net>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Richard Weinberger <richard@....at>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Michal Hocko <mhocko@...e.cz>
Subject: Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

Hello,

(cc'ing Johannes and Michal, hi guys)

On Fri, May 04, 2012 at 08:17:11AM +0900, Hiroyuki Kamezawa wrote:
> > Cgroups is moving to a single hierarchy for simplification, this isn't the
> > only example of where this is currently suboptimal and it would be
> > disappointing to solidify hugetlb control as part of memcg because of this
> > current limitation that will be addressed by generic cgroups development.
> >
> > Folks, once these things are merged they become an API that can't easily
> > be shifted around and seperated out later.  The decision now is either to
> > join hugetlb control with memcg forever when they act in very different
> > ways or to seperate them so they can be used and configured individually.
> 
> How do other guys think ? Tejun ?

I don't know.  hugetlbfs already is this franken thing which is
separate from the usual memory management.  It needing cgroup type
resource limitation feels a bit weird to me.  Isn't this supposed to
be used in more-or-less tightly controlled setups?  The whole thing
needs to have its memory cut out from boot after all.

If someone really has to add cgroup support to hugetlbfs, I'm more
inclined to say let them play in their own corner unless incorporating
it into memcg makes it inherently better.

That said, I really don't know that much about mm.  Johannes, Michal,
what do you guys think?

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/