Re: [PATCH v3 4/4] mm: swap: Swap-out small-sized THP without splitting

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.

--
Cheers,

David / dhildenb





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux