On Wed, Jan 10, 2024 at 4:35 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Wed, Jan 10, 2024 at 05:28:22PM +0200, Joonas Lahtinen wrote: > > Quoting Joonas Lahtinen (2024-01-10 17:20:24) > > > However we specifically pass "huge=within_size" to vfs_kern_mount when > > > creating a private mount of tmpfs for the purpose of i915 created > > > allocations. > > > > > > Older hardware also had some address hashing bugs where 2M aligned > > > memory caused a lot of collisions in TLB so we don't enable it always. > > > > > > You can see drivers/gpu/drm/i915/gem/i915_gemfs.c function > > > i915_gemfs_init for details and references. > > > > > > So in short, functionality wise we should be fine either default > > > for using 2M pages or not. If they become the default, we'd probably > > > want an option that would still be able to prevent them for performance > > > regression reasons on older hardware. > > > > To maybe write out my concern better: > > > > Is there plan to enable huge pages by default in shmem? > > Not in the next kernel release, but eventually the plan is to allow > arbitrary order folios to be used in shmem. So you could ask it to create > a 256kB folio for you, if that's the right size to manage memory in. > > How shmem and its various users go about choosing the right size is not > quite clear to me yet. Perhaps somebody else will do it before I get > to it; I have a lot of different sub-projects to work on at the moment, > and shmem isn't blocking any of them. And I have a sneaking suspicion > that more work is needed in the swap code to deal with arbitrary order > folios, so that's another reason for me to delay looking at this ;-) I have sent large folios support for shmem for the write and fallocate path some releases ago. The main problem I was facing was a current upstream problem with huge pages when seeking holes/data (fstests generic/285 and generic/436). The strategy suggested was to use large folios in an opportunistic way based on the file size. This hit the same problem we currently have with huge pages and I considered that a regression. We have made some progress to fix seeking in huge pages upstream but is not yet finished. I can send the patches tomorrow for further discussion. >
