David Gibson <d...@au1.ibm.com> writes: > On Mon, Apr 29, 2013 at 01:07:22AM +0530, Aneesh Kumar K.V wrote: >> From: "Aneesh Kumar K.V" <aneesh.ku...@linux.vnet.ibm.com> >> >> On archs like powerpc that support different hugepage sizes, HPAGE_SHIFT >> and other derived values like HPAGE_PMD_ORDER are not constants. So move >> that to hugepage_init > > These seems to miss the point. Those variables may be defined in > terms of HPAGE_SHIFT right now, but that is of itself kind of broken. > The transparent hugepage mechanism only works if the hugepage size is > equal to the PMD size - and PMD_SHIFT remains a compile time constant. > > There's no reason having transparent hugepage should force the PMD > size of hugepage to be the default for other purposes - it should be > possible to do THP as long as PMD-sized is a possible hugepage size. >
THP code does #define HPAGE_PMD_SHIFT HPAGE_SHIFT #define HPAGE_PMD_MASK HPAGE_MASK #define HPAGE_PMD_SIZE HPAGE_SIZE I had two options, one to move all those in terms of PMD_SHIFT or switch ppc64 to not use HPAGE_SHIFT the way it use now. Both would involve large code changes. Hence I end up moving some of the checks to runtime checks. Actual HPAGE_SHIFT == PMD_SHIFT check happens in the has_transparent_hugepage() https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-April/106002.html IMHO what the patch is checking is that, HPAGE_SHIFT value is not resulting in a page order higher than MAX_ORDER. Related to Reviewed-by: that came from V5 patchset https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-April/105299.html Your review suggestion to move that runtime check back to macro happened in V6. I missed dropping reviewed-by after that. -aneesh _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
