On Fri, 27 Apr 2012 14:27:13 -0700 (PDT) David Rientjes <rientjes@xxxxxxxxxx> 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. Minor matter: that's non-responsive to my suggestion. 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! -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
