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:	Thu, 3 May 2012 19:30:37 +0900
From:	Hiroyuki Kamezawa <kamezawa.hiroyuki@...il.com>
To:	David Rientjes <rientjes@...gle.com>
Cc:	"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>
Subject: Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

On Thu, May 3, 2012 at 6:13 PM, David Rientjes <rientjes@...gle.com> wrote:
> On Sat, 28 Apr 2012, Aneesh Kumar K.V wrote:
>
>> 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.
>>
>
> Maybe Kame can speak up if he feels strongly about this, but I really
> think it should be its own controller in its own file (which would
> obviously make this discussion irrelevant since mm/hugetlbcg.c would be
> dependent on your own config symbol).  I don't feel like this is the same
> as kmem since its not a global resource like hugetlb pages are.
>
> Hugetlb pages can either be allocated statically on the command line at
> boot or dynamically via sysfs and they are globally available to whoever
> mmaps them through hugetlbfs.  I see a real benefit from being able to
> limit the number of hugepages in the global pool to a set of tasks so they
> can't overuse what has been statically or dynamically allocated.  And that
> ability should be available, in my opinion, without having to enable
> memcg, the page_cgroup metadata overhead that comes along with it, and the
> performance impact in using it.  I also think it would be wise to seperate
> it out into its own file at the source level so things like this don't
> arise in the future.
>
> What do you think?  Kame?

I think hugetlb should be handled under memcg.

1. I think Hugetlb is memory.

2. The characteristics of hugetlb usage you pointed out is
characteristics comes from
   "current" implementation.
    Yes, it's now unreclaimable and should be allocated by hands of
admin. But,
    considering recent improvements, memory-defrag, CMA, it can be less
    hard-to-use thing by updating implementation and on-demand allocation
    can be allowed.

3. If overhead is the problem, and it's better to disable memcg,
    Please show numbers with HPC apps. I didn't think memcg has very
bad overhead
    with Bull's presentation in collaboration summit, this April.

4. I guess a user who uses hugetlbfs will use usual memory at the same time.
    Having 2 hierarchy for memory and hugetlb will bring him a confusion.

Thanks,
-Kame
--
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/