linux-kernel - Re: [PATCH v2] mm: shmem: fix the shmem large folio allocation for the i915 driver

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] [day] [month] [year] [list]

Message-ID: <CAJCW39+3whWNZ7PV606cewqvdGrE18BTbnDLZ_Py=6nvV+vseQ@mail.gmail.com>
Date: Thu, 31 Jul 2025 16:50:59 +0200
From: Patryk Kowalczyk <patryk@...alczyk.ws>
To: Baolin Wang <baolin.wang@...ux.alibaba.com>
Cc: akpm@...ux-foundation.org, hughd@...gle.com, ville.syrjala@...ux.intel.com, 
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] mm: shmem: fix the shmem large folio allocation for
 the i915 driver

That patch solved problem with the i915 performance regression, so the
previous patch for the i915 driver shoudn't be merged.
best regards,
Patryk Kowalczyk

czw., 31 lip 2025 o 03:54 Baolin Wang <baolin.wang@...ux.alibaba.com>
napisał(a):
>
> After commit acd7ccb284b8 ("mm: shmem: add large folio support for tmpfs"),
> we extend the 'huge=' option to allow any sized large folios for tmpfs,
> which means tmpfs will allow getting a highest order hint based on the size
> of write() and fallocate() paths, and then will try each allowable large order.
>
> However, when the i915 driver allocates shmem memory, it doesn't provide hint
> information about the size of the large folio to be allocated, resulting in
> the inability to allocate PMD-sized shmem, which in turn affects GPU performance.
>
> Patryk added:
>
> : In my tests, the performance drop ranges from a few percent up to 13%
> : in Unigine Superposition under heavy memory usage on the CPU Core Ultra
> : 155H with the Xe 128 EU GPU.  Other users have reported performance
> : impact up to 30% on certain workloads.  Please find more in the
> : regressions reports:
> : https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14645
> : https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13845
> :
> : I believe the change should be backported to all active kernel branches
> : after version 6.12.
>
> To fix this issue, we can use the inode's size as a write size hint in
> shmem_read_folio_gfp() to help allocate PMD-sized large folios.
>
> Fixes: acd7ccb284b8 ("mm: shmem: add large folio support for tmpfs")
> Reported-by: Patryk Kowalczyk <patryk@...alczyk.ws>
> Reported-by: Ville Syrjälä <ville.syrjala@...ux.intel.com>
> Tested-by: Patryk Kowalczyk <patryk@...alczyk.ws>
> Suggested-by: Hugh Dickins <hughd@...gle.com>
> Signed-off-by: Baolin Wang <baolin.wang@...ux.alibaba.com>
> ---
> Changes from v1:
>  - Use inode size as the write size hint, per Hugh.
> ---
>  mm/shmem.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 41eb4aa60be5..e1e5d5f7f58d 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -5989,8 +5989,8 @@ struct folio *shmem_read_folio_gfp(struct address_space *mapping,
>         struct folio *folio;
>         int error;
>
> -       error = shmem_get_folio_gfp(inode, index, 0, &folio, SGP_CACHE,
> -                                   gfp, NULL, NULL);
> +       error = shmem_get_folio_gfp(inode, index, i_size_read(inode),
> +                                   &folio, SGP_CACHE, gfp, NULL, NULL);
>         if (error)
>                 return ERR_PTR(error);
>
> --
> 2.43.5
>