On Jun 15, 2012, at 1:11 PM, Scott Wood wrote: > On 06/15/2012 09:43 AM, telenn barz wrote: >> Hi all, >> >> CONFIG_PHYS_64BIT enables kernel support for larger than 32-bit physical >> addresses. Is it this configuration option we have to enable for the >> support of 36-bit real memory (as are capable the Freescale e500v2 or >> e500mc cores family) ? > > Yes. > >> The Hugetlb patch for BookE >> (https://lists.ozlabs.org/pipermail/linuxppc-dev/2011-June/091315.html) >> seems to be surbordinated to CONFIG_PHYS_64BIT. Is there any good reason >> why it is not supported when CONFIG_PHYS_64BIT is disabled ? > > Because it would be extra work to support that configuration, and > nobody's felt enough of a need for it to put in that work.
Most of the use-cases we had demanding hugetlb were *also* cases that had large amounts of memory, so this is the model we adopted. Plus, we need some of the code from the 36-bit implementation, including the part that causes the lowest level of the page table to widen to 64 bits; additionally we did not measure much, if any, of a perf hit when enabling PHYS_64BIT. Obviously, it could be made to work without it, although there are real code changes required. But unless you have a case where you have a noticeable performance drop from enabling CONFIG_PHYS_64BIT, it's not worth the effort. -Becky > > -Scott > > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev