Messages in this thread | | | From | Suren Baghdasaryan <> | Date | Tue, 12 Oct 2021 10:01:05 -0700 | Subject | Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting |
| |
On Tue, Oct 12, 2021 at 12:44 AM David Hildenbrand <david@redhat.com> wrote: > > > I'm still evaluating the proposal to use memfds but I'm not sure if > > the issue that David Hildenbrand mentioned about additional memory > > consumed in pagecache (which has to be addressed) is the only one we > > will encounter with this approach. If anyone knows of any potential > > issues with using memfds as named anonymous memory, I would really > > appreciate your feedback before I go too far in that direction. > > [MAP_PRIVATE memfd only behave that way with 4k, not with huge pages, so > I think it just has to be fixed. It doesn't make any sense to allocate a > page for the pagecache ("populate the file") when accessing via a > private mapping that's supposed to leave the file untouched] > > My gut feeling is if you really need a string as identifier, then try > going with memfds. Yes, we might hit some road blocks to be sorted out, > but it just logically makes sense to me: Files have names. These names > exist before mapping and after mapping. They "name" the content.
I'm investigating this direction. I don't have much background with memfds, so I'll need to digest the code first.
> > Maybe it's just me, but the whole interface, setting the name via a > prctl after the mapping was already instantiated doesn't really spark > joy at my end. That's not a strong pushback, but if we can avoid it > using something that's already there, that would be very much preferred.
Actually that's one of my worries about using memfds. There might be cases when we need to name a vma after it was mapped. memfd_create() would not allow us to do that AFAIKT. But I need to check all usages to say if that's really an issue. Thanks!
> > -- > Thanks, > > David / dhildenb > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. >
| |