On 2021/2/19 15:45, Nicholas Piggin wrote: > Excerpts from Ding Tianhong's message of February 19, 2021 1:45 pm: >> Hi Nicholas: >> >> I met some problem for this patch, like this: >> >> kva = vmalloc(3*1024k); >> >> remap_vmalloc_range(xxx, kva, xxx) >> >> It failed because that the check for page_count(page) is null so return, it break the some logic for current modules. >> because the new huge page is not valid for composed page. > > Hey Ding, that's a good catch. How are you testing this stuff, do you > have a particular driver that does this? > yes, The driver would get a memory from the vmalloc in kernel space, and then the physical same memory will mmap to the user space. The drivers could not work when applying this patch. >> I think some guys really don't get used to the changes for the vmalloc that the small pages was transparency to the hugepage >> when the size is bigger than the PMD_SIZE. > > I think in this case vmalloc could allocate the large page as a compound > page which would solve this problem I think? (without having actually > tested it) > yes, i think the __GFP_COMP flag could fix this. >> can we think about give a new static huge page to fix it? just like use a a new vmalloc_huge_xxx function to disginguish the current function, >> the user could choose to use the transparent hugepage or static hugepage for vmalloc. > > Yeah that's a good question, there are a few things in the huge vmalloc > code that accounts things as small pages and you can't assume large or > small. If there is benefit from forcing large pages that could certainly > be added. > The vmalloc transparent is good, but not fit every user scenes, some guys like to use the deterministic function for performance critical area. Thanks Ding > Interestingly, remap_vmalloc_range in theory could map the pages as > large in userspace as well. That takes more work but if something > really needs that for performance, it could be done. > > Thanks, > Nick > . >
