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: <alpine.DEB.2.00.1204271611500.10429@chino.kir.corp.google.com>
Date:	Fri, 27 Apr 2012 16:14:52 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
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>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Subject: Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

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.
> 
> Minor matter: that's non-responsive to my suggestion.
> 

If it's moved to a new cgroup then we can just go back to the original 
point that I made as was trying to avoid: adding #ifdefs all over 
mm/memcontrol.c in a dozen or so places.  A mm/hugetlbcg.c would only be 
built, natually, when we have "depends on HUGETLB_PAGE" and 
linux/hugetlb.h takes care of the rest (setting HUGE_MAX_HSTATE for archs 
that don't define it themselves, in other words only one hugepage size).

> Major matter: that's a big fat nack to this patchset:
> 
> hugetlb-rename-max_hstate-to-hugetlb_max_hstate.patch
> hugetlbfs-dont-use-err_ptr-with-vm_fault-values.patch
> hugetlbfs-add-an-inline-helper-for-finding-hstate-index.patch
> hugetlb-use-mmu_gather-instead-of-a-temporary-linked-list-for-accumulating-pages.patch
> hugetlb-use-mmu_gather-instead-of-a-temporary-linked-list-for-accumulating-pages-fix.patch
> hugetlb-use-mmu_gather-instead-of-a-temporary-linked-list-for-accumulating-pages-fix-fix.patch
> hugetlb-avoid-taking-i_mmap_mutex-in-unmap_single_vma-for-hugetlb.patch
> hugetlb-simplify-migrate_huge_page.patch
> memcg-add-hugetlb-extension.patch
> memcg-add-hugetlb-extension-fix.patch
> hugetlb-add-charge-uncharge-calls-for-hugetlb-alloc-free.patch
> memcg-track-resource-index-in-cftype-private.patch
> hugetlbfs-add-memcg-control-files-for-hugetlbfs.patch
> hugetlbfs-add-memcg-control-files-for-hugetlbfs-use-scnprintf-instead-of-sprintf.patch
> hugetlbfs-add-memcg-control-files-for-hugetlbfs-use-scnprintf-instead-of-sprintf-fix.patch
> hugetlbfs-add-a-list-for-tracking-in-use-hugetlb-pages.patch
> memcg-move-hugetlb-resource-count-to-parent-cgroup-on-memcg-removal.patch
> memcg-move-hugetlb-resource-count-to-parent-cgroup-on-memcg-removal-fix.patch
> memcg-move-hugetlb-resource-count-to-parent-cgroup-on-memcg-removal-fix-fix.patch
> hugetlb-migrate-memcg-info-from-oldpage-to-new-page-during-migration.patch
> hugetlb-migrate-memcg-info-from-oldpage-to-new-page-during-migration-fix.patch
> memcg-add-memory-controller-documentation-for-hugetlb-management.patch
> 
> so please take it up at a convenient time, in the appropriate
> thread, with the appropriate cc's!
> 

No problem, and in the meantime, maybe Aneesh can talk about the 
ramifications of moving this out of memcg?
--
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/