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

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

On 5/13/26 09:47, Christian König wrote:
> Hi David & Thomas,
> 
> On 5/12/26 22:03, David Hildenbrand (Arm) wrote:
>> On 5/12/26 13:31, Thomas Hellström wrote:
> ...
>>>
>>> OK, can eliminate those. Is VM_WARN_ON_FOLIO() preferred,
>>> or any other type of assert?
>>
>> VM_WARN_ON_FOLIO() is usually what you want, or VM_WARN_ON_ONCE().
>>
>>>
>>>
>>> OK, let me understand the concern. The pages are allocated as multi-
>>> page folios using alloc_pages(gfp, order), but typically not promoted
>>> to compound pages, until inserted here. Is it that promotion that is of
>>> concern or inserting pages of unknown origin into shmem? Anything we
>>> can do to alleviate that concern?
>>
>> It's all rather questionable.
>>
>> A couple of points:
>>
>> a) The pages are allocated to be unmovable, but adding them to shmem effectively
>>    turns them movable. Now you interfere with the page allocator logic of
>>    placing movable and unmovable pages a reasonable way into
>>    pageblocks that group allocations of similar types.
>>
>> b) A driver is not supposed to decide which folio size will be allocated for
>>    shmem.
> 
> 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.

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

-- 
Cheers,

David