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-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
