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, > > > > 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.
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. 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. 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. Thanks, Thomas
