On 06/10/2019 08:14 PM, Nicholas Piggin wrote: > Mark Rutland's on June 11, 2019 12:10 am: >> Hi, >> >> On Mon, Jun 10, 2019 at 02:38:38PM +1000, Nicholas Piggin wrote: >>> For platforms that define HAVE_ARCH_HUGE_VMAP, have vmap allow vmalloc to >>> allocate huge pages and map them >>> >>> This brings dTLB misses for linux kernel tree `git diff` from 45,000 to >>> 8,000 on a Kaby Lake KVM guest with 8MB dentry hash and mitigations=off >>> (performance is in the noise, under 1% difference, page tables are likely >>> to be well cached for this workload). Similar numbers are seen on POWER9. >> >> Do you happen to know which vmalloc mappings these get used for in the >> above case? Where do we see vmalloc mappings that large? > > Large module vmalloc could be subject to huge mappings. > >> I'm worried as to how this would interact with the set_memory_*() >> functions, as on arm64 those can only operate on page-granular mappings. >> Those may need fixing up to handle huge mappings; certainly if the above >> is all for modules. > > Good point, that looks like it would break on arm64 at least. I'll > work on it. We may have to make this opt in beyond HUGE_VMAP. This is another reason we might need to have an arch opt-ins like the one I mentioned before.
