linux-kernel - Re: [REGRESSION] Re: [PATCH v3 3/6] mm: shmem: add large folio support for tmpfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aBIHYqzar5J8uxGO@intel.com>
Date: Wed, 30 Apr 2025 14:20:02 +0300
From: Ville Syrjälä <ville.syrjala@...ux.intel.com>
To: Baolin Wang <baolin.wang@...ux.alibaba.com>
Cc: akpm@...ux-foundation.org, hughd@...gle.com, willy@...radead.org,
	david@...hat.com, wangkefeng.wang@...wei.com, 21cnbao@...il.com,
	ryan.roberts@....com, ioworker0@...il.com, da.gomez@...sung.com,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	regressions@...ts.linux.dev, intel-gfx@...ts.freedesktop.org,
	Eero Tamminen <eero.t.tamminen@...el.com>
Subject: Re: [REGRESSION] Re: [PATCH v3 3/6] mm: shmem: add large folio
 support for tmpfs

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.gomez@...sung.com>
> >> Signed-off-by: Daniel Gomez <da.gomez@...sung.com>
> >> Signed-off-by: Baolin Wang <baolin.wang@...ux.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