On Thu, Sep 26, 2024 at 10:20:54PM +0800, Kefeng Wang wrote: > On 2024/9/26 21:52, Matthew Wilcox wrote: > > On Thu, Sep 26, 2024 at 10:38:34AM +0200, Pankaj Raghav (Samsung) wrote: > > > > So this is why I don't use mapping_set_folio_order_range() here, but > > > > correct me if I am wrong. > > > > > > Yeah, the inode is active here as the max folio size is decided based on > > > the write size, so probably mapping_set_folio_order_range() will not be > > > a safe option. > > > > You really are all making too much of this. Here's the patch I think we > > need: > > > > - mapping_set_large_folios(inode->i_mapping); > > + if (sbinfo->huge) > > + mapping_set_large_folios(inode->i_mapping); > > But it can't solve all issue, eg, > mount with huge = SHMEM_HUGE_WITHIN_SIZE, or The page cache will not create folios which overhang the end of the file by more than the minimum folio size for that mapping. So this is wrong. > mount with SHMEM_HUGE_ALWAYS + runtime SHMEM_HUGE_DENY That's a tweak to this patch, not a fundamental problem with it. > and the above change will break > mount with SHMEM_HUGE_NEVER + runtime SHMEM_HUGE_FORCE Likewise.
