[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120507170840.GA19417@google.com>
Date: Mon, 7 May 2012 10:08:40 -0700
From: Tejun Heo <tj@...nel.org>
To: Michal Hocko <mhocko@...e.cz>
Cc: Hiroyuki Kamezawa <kamezawa.hiroyuki@...il.com>,
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>
Subject: Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)
Hello,
On Mon, May 07, 2012 at 04:01:04PM +0200, Michal Hocko wrote:
> > 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.
>
> I would agree with you but my impression from the previous (hugetlb)
> implementation was that it is much harder to implement the charge moving
> if we do not use page_cgroup.
> Also the range tracking is rather ugly and clumsy.
Understood. I haven't looked at the code, so my opinion was based on
the assumption that the whole thing is completely separate (in design
and implementation) from memcg as hugtlbfs is from the usual mm. If
it's better / easier implemented together with memcg, I have no
objection to making it part of memcg.
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/
Powered by blists - more mailing lists