On 5/13/26 16:53, Thomas Hellström wrote: > On Wed, 2026-05-13 at 13:36 +0200, David Hildenbrand (Arm) wrote: >> On 5/13/26 12:37, Thomas Hellström wrote: >> >> >>> > [...] >>> One alternative would be a single large sparse shmem object common >>> for >>> all DRM objects, with a range allocator, but that also got pretty >>> ugly >>> when I tried to implement that. >> >> Does not sound too crazy, though. >> >>> > > Yeah, I stumbled on finding a reasonable idea to connect a shmem folio > to the pool LRUs and the range allocator metadata. > > Assuming a shmem folio is pinned using the memfd pinning interface, > would folio->private be temporarily available?
I think shmem uses folio->private only when the folio is in the swapcache (through folio->swap). So one has to protect against that. So you're thinking of a model, where a shmem file is essentially fully "owned" by a DRM object, and that owner could make use of folio->private as long as the folio is prevented from getting swapped out? (e.g., longterm pinned etc) -- Cheers, David
