> On Apr 5, 2022, at 12:07 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Fri, Apr 01, 2022 at 10:22:00PM +0000, Song Liu wrote: >>>> Please fix the underlying issues instead of papering over them and >>>> creating a huge maintainance burden for others. >> >> After reading the code a little more, I wonder what would be best strategy. >> IIUC, most of the kernel is not ready for huge page backed vmalloc memory. >> For example, all the module_alloc cannot work with huge pages at the moment. >> And the error Paul Menzel reported in drm_fb_helper.c will probably hit >> powerpc with 5.17 kernel as-is? (trace attached below) >> >> Right now, we have VM_NO_HUGE_VMAP to let a user to opt out of huge pages. >> However, given there are so many users of vmalloc, vzalloc, etc., we >> probably do need a flag for the user to opt-in? >> >> Does this make sense? Any recommendations are really appreciated. > > I think there is multiple aspects here: > > - if we think that the kernel is not ready for hugepage backed vmalloc > in general we need to disable it in powerpc for now. Nicholas and Claudio, What do you think about the status of hugepage backed vmalloc on powerpc? I found module_alloc and kvm_s390_pv_alloc_vm() opt-out of huge pages. But I am not aware of users that benefit from huge pages (except vfs hash, which was mentioned in 8abddd968a30). Does an opt-in flag (instead of current opt-out flag, VM_NO_HUGE_VMAP) make sense to you? Thanks, Song > - if we think even in the longer run only some users can cope with > hugepage backed vmalloc we need to turn it into an opt-in in > general and not just for x86 > - there still to appear various unresolved underlying x86 specific > issues that need to be fixed either way
