Quoting Joonas Lahtinen (2024-01-10 17:20:24) > Quoting Matthew Wilcox (2024-01-10 14:37:18) > > On Wed, Jan 10, 2024 at 10:21:07AM +0100, Christoph Hellwig wrote: > > > Hi all, > > > > > > Darrick reported that the fairly new XFS xfile code blows up when force > > > enabling large folio for shmem. This series fixes this quickly by disabling > > > large folios for this particular shmem file for now until it can be fixed > > > properly, which will be a lot more invasive. > > > > > > I've added most of you to the CC list as I suspect most other users of > > > shmem_file_setup and friends will have similar issues. > > > > The graphics users _want_ to use large folios. I'm pretty sure they've > > been tested with this. > > Correct. We've done quite a bit of optimization in userspace and > enabling in kernel to take advantage of page sizes of 2M and beyond. > > 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? If not I guess we should be pretty good with the way current code is, force enabling them just might bring out some performance, so we might want to add a warning for that. If there is, then we'll probably want to in sync with those default changes apply a similar call to block them on older HW. Regards, Joonas > > Regards, Joonas > > > It's just XFS that didn't know about this > > feature of shmem.
