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]

Message-ID: <87fwbnag6u.fsf@skywalker.in.ibm.com>
Date:	Sat, 28 Apr 2012 23:31:45 +0530
From:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	Andrew Morton <akpm@...ux-foundation.org>,
	David Rientjes <rientjes@...gle.com>
Cc:	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>
Subject: Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

Andrew Morton <akpm@...ux-foundation.org> writes:

> On Fri, 27 Apr 2012 14:27:13 -0700 (PDT)
> David Rientjes <rientjes@...gle.com> wrote:
>
>> On Fri, 27 Apr 2012, Andrew Morton wrote:
>> 
>> > Seems reasonable.  But the CONFIG_HUGETLB_PAGE=y,
>> > CONFIG_MEM_RES_CTLR_HUGETLB=n combination will cause unneeded code
>> > generation and space consumption in memcontrol.c.
>> > 
>> > I wonder if we can additionally do, within memcontrol.c:
>> > 
>> > /*
>> >  * Nice comment goes here
>> >  */
>> > #ifdef CONFIG_MEM_RES_CTLR_HUGETLB
>> > #define HUGE_MAX_HSTATE_FOO HUGE_MAX_HSTATE
>> > #else
>> > #define HUGE_MAX_HSTATE_FOO 0
>> > #endif
>> > 
>> > and s/HUGE_MAX_HSTATE/HUGE_MAX_HSTATE_FOO/ in that file.
>> > 
>> 
>> I haven't looked at the hugetlb memcg controller in-depth (yet), but I 
>> really think we should start considering breaking things like this off 
>> into its own cgroup.  The hugetlb extension seems like something that 
>> could be easily separtated, but perhaps I'm saying "easily" because I 
>> haven't looked at the implementation.
>> 
>> mm/memcontrol.c in linux-next is 5877 lines and, if history is any guide, 
>> it's going to continue growing.
>> 
>> If the hugetlb usage isn't charged against the memcg's 
>> memory.usage_in_bytes like thp is, then I really think it should be its 
>> own cgroup.  From the hugetlb perspective absent any cgroups, things like 
>> hstates (since we're talking about HUGE_MAX_HSTATE) are global resources 
>> and so you'd need to preallocate these on the command line or via sysfs 
>> before you could mmap them.  So if my assumption that the hugetlb memcg 
>> controller is only governing these global resources and charging a set of 
>> tasks for what they use, then it really has no business in mm/memcontrol.c 
>> to begin with, in my opinion.
>

My first version was to do it as a seperate controller 

http://thread.gmane.org/gmane.linux.kernel.mm/73826

But the feedback I received was to do it as a part of memcg extension,
because what the controller is limiting is memory albeit a different
type. AFAIU there is also this goal of avoiding controller proliferation.

-aneesh

--
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/