Re: [PATCH 1/2] mm/shmem: add shmem_insert_folio()

["David Hildenbrand (Arm)" <david@kernel.org>]

On 5/13/26 10:51, Thomas Hellström wrote:
> On Wed, 2026-05-13 at 10:37 +0200, David Hildenbrand (Arm) wrote:
>> On 5/13/26 09:47, Christian König wrote:
>>> Hi David & Thomas,
>>>
>>> ...
>>>
>>> Exactly that is one of the major reasons why we aren't using a
>>> shmem as backing store for TTM buffers in the first place.
>>
>> What was the problem with that the last time this was considered?
>>
>> shmem nowadays supports THP (e.g., 2M) and even mTHP (e.g., 64K).
>>
>> For internal mounts, it must be enabled accordingly
>> (/sys/kernel/mm/transparent_hugepage/.../shmem_enabled).
>>
>> Some distributions still default to "never". I guess if an admin
>> enables it, you
>> would just get THPs.
> 
> FWIW, the i915 driver which uses shmem "natively" uses a special mount
> here that gives back THPs.
> 
>>
>> If "distro default" is the only problem, I guess we could think about
>> how to
>> improve that. For example, just let internal GPU DRM objects allocate
>> any folio
>> size available and supported etc.
>>
>> Would that make it possible to just use shmem natively? (e.g., how
>> would this
>> interact with shmem features like folio migration, would that be
>> workable with
>> DRM objects?).
> 
> Currently the drivers that use shmem in this way use
> "mapping_set_unevictable()" as long as the object is bound to the GPU.
> Then shrinkers can unbind from GPU and revert that setting.

Right, but mapping_set_unevictable() only affects folio_evictable() - -reclaim
behavior. Not other properties (such as folio migration).

> 
> The problem, (as also stated in the cover letter of this series) is for
> drivers that need to change caching of the pages to WC or UC.

I assume you mean "To be able to easily maintain pools of pages mapped uncached
or write-combined".

Can you point me at the code that changes the caching of the pages?

> That's an
> extremely costly operation so TTM needs to pool such allocations.
> That's where using shmem natively becomes very ugly, because you can't
> really use a 1:1 mapping between shmem objects and DRM objects anymore.

So you would require different caching attributes within a DRM object?

-- 
Cheers,

David