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

[Baolin Wang <baolin.wang@linux.alibaba.com>]

On 2025/7/25 16:36, Patryk Kowalczyk wrote:
> 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.

Thanks for testing. I need to wait for Hugh's opinion before sending out 
a formal fix patch.

> Additionally, I also see potential for further optimization of the Xe
> driver.

If you can guide me where the Xe driver allocates shmem memory, I can 
help with the fix. Thanks.

>> 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.
>>
>>
>