On Wed, Feb 28, 2024 at 10:34 PM David Hildenbrand <david@xxxxxxxxxx> wrote: > > >>>>> > >>>>> To me, it seems safer to split or do some other similar optimization if we find a > >>>>> large folio has partial map and unmap. > >>>> > >>>> I'm hoping that we can avoid any new direct users of _nr_pages_mapped if > >>>> possible. > >>>> > >>> > >>> Is _nr_pages_mapped < nr_pages a reasonable case to split as we > >>> have known the folio has at least some subpages zapped? > >> > >> I'm not sure we need this - the folio's presence on the split list will tell us > >> everything we need to know I think? > > > > I agree, this is just one question to David, not my proposal. if > > deferred_list is sufficient, > > I prefer we use deferred_list. > > > > I actually don't quite understand why David dislikes _nr_pages_mapped being used > > though I do think _nr_pages_mapped cannot precisely reflect how a > > folio is mapped > > by multi-processes. but _nr_pages_mapped < nr_pages seems be safe to > > tell the folio > > is partially unmapped :-) > > I'm hoping we can get rid of _nr_pages_mapped in some kernel configs in > the future (that's what I am working on). So the less we depend on it > the better. > > With the total mapcount patch I'll revive shortly, _nr_pages_mapped will > only be used inside rmap code. I'm hoping we won't have to introduce > other users that will be harder to get rid of. > > So please, if avoidable, no usage of _nr_pages_mapped outside of core > rmap code. Thanks for clarification on the plan. good to use deferred_list in this swap-out case. > > -- > Cheers, > > David / dhildenb > Thanks Barry
