Re: [REGRESSION] Re: [PATCH v3 3/6] mm: shmem: add large folio support for tmpfs
From: David Hildenbrand
Date: Fri May 02 2025 - 03:18:55 EST
On 02.05.25 03:02, Baolin Wang wrote:
On 2025/4/30 21:24, Daniel Gomez wrote:
On Wed, Apr 30, 2025 at 02:20:02PM +0100, Ville Syrjälä wrote:
On Wed, Apr 30, 2025 at 02:32:39PM +0800, Baolin Wang wrote:
On 2025/4/30 01:44, Ville Syrjälä wrote:
On Thu, Nov 28, 2024 at 03:40:41PM +0800, Baolin Wang wrote:
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.
To enable mTHP on tmpfs, the necessary knobs must first be enabled in sysfs
as they are not enabled by default IIRC (only THP, PMD level). Ville, I
see i915_gemfs the huge=within_size mount option is passed. Can you confirm
if /sys/kernel/mm/transparent_hugepage/hugepages-*/enabled are also marked as
'always' when the regression is found?
The tmpfs mount will not be controlled by
'/sys/kernel/mm/transparent_hugepage/hugepages-*Kb/enabled' (except for
the debugging options 'deny' and 'force').
Right, IIRC as requested by Willy, it should behave like other FSes
where there is no control over the folio size to be used.
--
Cheers,
David / dhildenb