Anshuman Khandual's on June 11, 2019 4:17 pm: > > > 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. > Let's try to get the precursor stuff like page table functions and vmalloc_to_page in this merge window, and then concentrate on the huge vmalloc support issues after that. Christophe points out that powerpc is likely to have a similar problem which I didn't realise, so I'll re think it. Thanks, Nick
