On Wed, 2026-05-13 at 21:35 +0200, David Hildenbrand (Arm) wrote: > 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)
Yeah, exactly. Thanks, Thomas
