On 07/12/2019 12:37 PM, Michael Ellerman wrote:
Anshuman Khandual [off-list ref] writes:
quoted
On 07/03/2019 04:36 AM, Andrew Morton wrote:
quoted
On Fri, 28 Jun 2019 10:50:31 +0530 Anshuman Khandual [off-list ref] wrote:
quoted
Finishing up what the commit c2febafc67734a ("mm: convert generic code to
5-level paging") started out while levelling up P4D huge mapping support
at par with PUD and PMD. A new arch call back arch_ioremap_p4d_supported()
is being added which just maintains status quo (P4D huge map not supported)
on x86, arm64 and powerpc.
Does this have any runtime effects? If so, what are they and why? If
not, what's the actual point?
It just finishes up what the previous commit c2febafc67734a ("mm: convert
generic code to 5-level paging") left off with respect p4d based huge page
enablement for ioremap. When HAVE_ARCH_HUGE_VMAP is enabled its just a simple
check from the arch about the support, hence runtime effects are minimal.
The return value of arch_ioremap_p4d_supported() is stored in the
variable ioremap_p4d_capable which is then returned by
ioremap_p4d_enabled().
That is used by ioremap_try_huge_p4d() called from ioremap_p4d_range()
from ioremap_page_range().
That is right.
The runtime effect is that it prevents ioremap_page_range() from trying
to create huge mappings at the p4d level on arches that don't support
it.
But now after first checking with an arch callback. Previously p4d huge
mappings were disabled on all platforms as ioremap_p4d_capable remained
clear through out being a static.