Excerpts from Nicholas Piggin's message of April 21, 2022 12:24 pm: > Excerpts from Song Liu's message of April 12, 2022 4:00 pm: >> On Mon, Apr 11, 2022 at 9:18 PM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: >>> >>> On Mon, Apr 11, 2022 at 04:35:46PM -0700, Song Liu wrote: >>> > Huge page backed vmalloc memory could benefit performance in many cases. >>> > Since some users of vmalloc may not be ready to handle huge pages, >>> > VM_NO_HUGE_VMAP was introduced to allow vmalloc users to opt-out huge >>> > pages. However, it is not easy to add VM_NO_HUGE_VMAP to all the users >>> > that may try to allocate >= PMD_SIZE pages, but are not ready to handle >>> > huge pages properly. >>> >>> This is a good place to document what the problems are, and how they are >>> hard to track down (e.g. because the allocations are passed down I/O >>> stacks) >> >> Will add it in v3. >> >>> >>> > >>> > Replace VM_NO_HUGE_VMAP with an opt-in flag, VM_ALLOW_HUGE_VMAP, so that >>> > users that benefit from huge pages could ask specificially. >>> > >>> > Also, replace vmalloc_no_huge() with opt-in helper vmalloc_huge(). >>> >>> We still need to find out what the primary users of the large vmalloc >>> hashes was and convert them. >> >> @ Claudio and Nicholas, >> >> Could you please help identify users of large vmalloc? So far, I found >> alloc_large_system_hash(), and something like the following seems to >> work: > > The large system hashes were the main ones I was interested in. IIRC > there was a few more in some drivers or tracing things depending on > config but those are less important (to me at least). Oh there is also a reverse map array in KVM now I think of it. Thanks, Nick
