On Fri, 27 Apr 2012, Andrew Morton wrote: > > > 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). > > And if it isn't moved to a new cgroup then your > memcg-add-hugetlb-extension-fix.patch is suboptimal. Why is this so > hard? > It _should_ be moved to a new cgroup: there's no reason why someone should need to enable memcg (and incur ~1% of metadata overhead that comes with it) if they just want to seperate a global hugepage pool amongst a set of tasks. Perhaps Aneesh has a reasoning behind this, I dunno. And yes, memcg-add-hugetlb-extension-fix.patch is a build fix for the linux-next breakage. If it's seperated out to mm/hugetlbcg.c, this is all irrelevant. I'd like to determine the direction of this feature before proposing any fixes for build breakage. In other words, if memcg-add-hugetlb-extension.patch is rewritten then memcg-add-hugetlb-extension-fix.patch is useless. -- 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
