Re: [PATCH RFC 00/39] mm/rmap: interface overhaul

[David Hildenbrand]

> > > > > > >
> > > > Regarding the contpte, I think it needs more work. Especially, as raised, to not
> > > > degrade
> > > > order-0 performance. Maybe we won't make the next merge window (and you already
> > > > predicated
> > > > that in some cover letter :P ). Let's see.
> > >
> > > Yeah that's ok. I'll do the work to fix the order-0 perf. And also do the same
> > > for patch 2 in that series - would also be really helpful if you had a chance to
> > > look at patch 2 - its new for v3.
> >
> > I only skimmed over it, but it seems to go into the direction we'll need.
> > Keeping order-0 performance unharmed should have highest priority. Hopefully my
> > microbenchmarks are helpful.
>
> Yes absolutely - are you able to share them??

I shared them in the reply to your patchset. Let me know if you can't 
find them.

[...]

> > > Having now reviewed your series, I have a less strong opinion, perhaps it's
> > > actually best with your original names; "folio" is actually the subject after
> > > all; it's the thing being operated on.
> >
> > I think having "folio" in there looks cleaner and more consistent to other
> > functions.
> >
> > I tend to like "rmap_dup_file_folio_[pte|ptes|pmd]()", because then we have
> > "file folio" and "anon folio" as one word.
> >
> > But then I wonder about the hugetlb part. Maybe simply
> > "hugetlb_rmap_remove_folio()" etc.
> >
> > Having the "hugetlb_" prefix at the beginning feels like the right thing to do,
> > looking at orher hugetlb special-handlings.
> >
> > But I'll wait a bit until I go crazy on renaming :)
>
> I suspect we could argue in multiple directions for hours :)

:)

> Let's see if others have opinions.
>
> FWIW, I've looked through all the patches; I like what I see! This is a really
> nice clean up and will definitely help with the various patch sets I've been
> working on. Apart from the comments I've already raised, looks in pretty good
> shape to me.

Thanks!

--
Cheers,

David / dhildenb