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 <[email protected]>
Signed-off-by: Daniel Gomez <[email protected]>
Signed-off-by: Baolin Wang <[email protected]>
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(), 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);
