On Fri, Mar 18, 2022 at 11:48 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Fri, Mar 18, 2022 at 11:04:29AM -0700, Yang Shi wrote: > > I agree once page cache huge page is fully supported, > > READ_ONLY_THP_FOR_FS could be deprecated. But actually this patchset > > makes khugepaged collapse file THP more consistently. It guarantees > > the THP could be collapsed as long as file THP is supported and > > configured properly and there is suitable file vmas, it is not > > guaranteed by the current code. So it should be useful even though > > READ_ONLY_THP_FOR_FS is gone IMHO. > > I don't know if it's a good thing or not. Experiments with 64k > PAGE_SIZE on arm64 shows some benchmarks improving and others regressing. > Just because we _can_ collapse a 2MB range of pages into a single 2MB > page doesn't mean we _should_. I suspect the right size folio for any > given file will depend on the access pattern. For example, dirtying a > few bytes in a folio will result in the entire folio being written back. > Is that what you want? Maybe! It may prompt the filesystem to defragment > that range, which would be good. On the other hand, if you're bandwidth > limited, it may decrease your performance. And if your media has limited > write endurance, it may result in your drive wearing out more quickly. > > Changing the heuristics should come with data. Preferably from a wide > range of systems and use cases. I know that's hard to do, but how else > can we proceed? TBH I don't think it belongs to "change the heuristics". Its users' decision if their workloads could benefit from huge pages or not. They could set THP to always/madivse/never per their workloads. The patchset is aimed to fix the misbehavior. The user visible issue is even though users enable READ_ONLY_THP_FOR_FS and configure THP to "always" (khugepaged always runs) and do expect their huge text section is backed by THP but THP may not be collapsed. > > And I think you ignored my point that READ_ONLY_THP_FOR_FS required > no changes to filesystems. It was completely invisible to them, by > design. Now this patchset requires each filesystem to do something. > That's not a great step. I don't mean to ignore your point. I do understand it is not perfect. I was thinking about making it FS agnostic in the first place. But I didn't think of a perfect way to do it at that time, so I followed what tmpfs does. However, by rethinking this we may be able to call khugepaged_enter_file() in filemap_fault(). I was concerned about the overhead in the page fault path. But it may be neglectable since khugepaged_enter_file() does bail out in the first place if the mm is already registered in khugepaged, just the first page fault needs to go through all the check, but the first page fault is typically a major fault so the overhead should be not noticeable comparing to the overhead of I/O. Calling khugepaged_enter() in page fault path is the approach used by anonymous THP too. > > P.S. khugepaged currently does nothing if a range contains a compound > page. It assumes that the page is compound because it's now a THP. > Large folios break that assumption, so khugepaged will now never > collapse a range which includes large folios. Thanks to commit > mm/filemap: Support VM_HUGEPAGE for file mappings > we'll always try to bring in PMD-sized pages for MADV_HUGEPAGE, so > it _probably_ doesn't matter. But it's something we should watch > for as filesystems grow support for large folios. Yeah, I agree, thanks for reminding this. In addition I think the users of READ_ONLY_THP_FOR_FS should also expect the PMD-sized THP to be collapsed for their usecase with full page cache THP support since their benefits come from reduced TLB miss.
