On Wed, Apr 30, 2025 at 02:32:39PM +0800, Baolin Wang wrote: > Hi, > > On 2025/4/30 01:44, Ville Syrjälä wrote: > > On Thu, Nov 28, 2024 at 03:40:41PM +0800, Baolin Wang wrote: > >> Add large folio support for tmpfs write and fallocate paths matching the > >> same high order preference mechanism used in the iomap buffered IO path > >> as used in __filemap_get_folio(). > >> > >> Add shmem_mapping_size_orders() to get a hint for the orders of the folio > >> based on the file size which takes care of the mapping requirements. > >> > >> Traditionally, tmpfs only supported PMD-sized large folios. However > >> nowadays > >> with other file systems supporting any sized large folios, and extending > >> anonymous to support mTHP, we should not restrict tmpfs to allocating only > >> PMD-sized large folios, making it more special. Instead, we should allow > >> tmpfs can allocate any sized large folios. > >> > >> Considering that tmpfs already has the 'huge=' option to control the > >> PMD-sized > >> large folios allocation, we can extend the 'huge=' option to allow any > >> sized > >> large folios. The semantics of the 'huge=' mount option are: > >> > >> huge=never: no any sized large folios > >> huge=always: any sized large folios > >> huge=within_size: like 'always' but respect the i_size > >> huge=advise: like 'always' if requested with madvise() > >> > >> Note: for tmpfs mmap() faults, due to the lack of a write size hint, still > >> allocate the PMD-sized huge folios if huge=always/within_size/advise is > >> set. > >> > >> Moreover, the 'deny' and 'force' testing options controlled by > >> '/sys/kernel/mm/transparent_hugepage/shmem_enabled', still retain the same > >> semantics. The 'deny' can disable any sized large folios for tmpfs, while > >> the 'force' can enable PMD sized large folios for tmpfs. > >> > >> Co-developed-by: Daniel Gomez <da.go...@samsung.com> > >> Signed-off-by: Daniel Gomez <da.go...@samsung.com> > >> Signed-off-by: Baolin Wang <baolin.w...@linux.alibaba.com> > > > > Hi, > > > > This causes a huge regression in Intel iGPU texturing performance. > > Unfortunately, I don't have such platform to test it. > > > > > I haven't had time to look at this in detail, but presumably the > > problem is that we're no longer getting huge pages from our > > private tmpfs mount (done in i915_gemfs_init()). > > IIUC, the i915 driver still limits the maximum write size to PAGE_SIZE > in the shmem_pwrite(),
pwrite is just one random way to write to objects, and probably not something that's even used by current Mesa. > which prevents tmpfs from allocating large > folios. As mentioned in the comments below, tmpfs like other file > systems that support large folios, will allow getting a highest order > hint based on the size of the write and fallocate paths, and then will > attempt each allowable huge order. > > Therefore, I think the shmem_pwrite() function should be changed to > remove the limitation that the write size cannot exceed PAGE_SIZE. > > Something like the following code (untested): > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c > b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c > index ae3343c81a64..97eefb73c5d2 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c > @@ -420,6 +420,7 @@ shmem_pwrite(struct drm_i915_gem_object *obj, > struct address_space *mapping = obj->base.filp->f_mapping; > const struct address_space_operations *aops = mapping->a_ops; > char __user *user_data = u64_to_user_ptr(arg->data_ptr); > + size_t chunk = mapping_max_folio_size(mapping); > u64 remain; > loff_t pos; > unsigned int pg; > @@ -463,10 +464,10 @@ shmem_pwrite(struct drm_i915_gem_object *obj, > void *data, *vaddr; > int err; > char __maybe_unused c; > + size_t offset; > > - len = PAGE_SIZE - pg; > - if (len > remain) > - len = remain; > + offset = pos & (chunk - 1); > + len = min(chunk - offset, remain); > > /* Prefault the user page to reduce potential recursion */ > err = __get_user(c, user_data); -- Ville Syrjälä Intel
