Re: regression - mm: shmem: add large folio support for tmpfs affect GPU performance.

[Patryk Kowalczyk <patryk@kowalczyk.ws>]

[-- Attachment #1: Type: text/plain, Size: 3211 bytes --]

I have tested the fix for the i915 driver with kernel 6.16-rc7 and intel
core ultra 155H.
The performance in several tests is on the kernel 6.12 level,
so from a functional standpoint, the issue has been resolved.
Additionally, I also see potential for further optimization of the Xe
driver.

regards,
Patryk
pt., 25 lip 2025 o 08:05 Baolin Wang <baolin.wang@linux.alibaba.com>
napisał(a):

>
>
> On 2025/7/25 12:47, Hugh Dickins wrote:
> > On Fri, 25 Jul 2025, Baolin Wang wrote:
> >>>
> >>> I hope to correct the logic of i915 driver's shmem allocation, by
> extending
> >>> the shmem write length in the i915 driver to allocate PMD- sized THPs.
> IIUC,
> >>> some sample fix code is as follows (untested). Patryk, could you help
> test
> >>> it to see if this resolves your issue? Thanks.
> >
> > This patch cannot be the right fix.  It may be a very sensible workaround
> > for some in-kernel drivers (I've not looked or tried); but unless I
> > misunderstand, it does nothing to restore userspace behaviour on a
> > huge=always tmpfs.
>
> Yes. Initially, we wanted to maintain compatibility with the 'huge='
> option, meaning that 'huge=always' tmpfs mount would still allocate
> PMD-sized THPs. However, the current implementation is the consensus we
> reached after much debate:
>
> 1. “When using tmpfs as a filesystem, it should behave like other
> filesystems. No more special mount options.” Per Matthew.
> 2. “Do not let the 'huge=' mount option mean 'PMD-sized' when other
> sizes exist.” Per David.
>
> At the time, we should have sought your advice, but we failed. The long
> historical discussion is in this thread[1]. So now the strategy for
> tmpfs supporting large folios is:
>
> "
> 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 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 large 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.
> "
>
> Currently, we have observed regression in the i915 driver but have not
> yet seen userspace regression on a huge=always tmpfs.
>
> If you have better suggestions, please feel free to point them out. Thanks.
>
> [1] https://lore.kernel.org/lkml/Zw_IT136rxW_KuhU@casper.infradead.org/
>
> > Please reread my comment earlier in the thread, in particular,
> > Passing a new SIGBUS xfstest does not excuse a regression: strict
> PAGE_SIZE
> > SIGBUS behaviour is fine for the newly-featured mTHPs or large folios,
> > but not for the long-established huge=always.
>
>

[-- Attachment #2: Type: text/html, Size: 4042 bytes --]