On Wed 30-06-21 12:22:48, Matthew Wilcox wrote:
> On Wed, Jun 30, 2021 at 10:30:38AM +0200, Michal Hocko wrote:
> > > - if (PageAnon(page)) {
> > > - if (page_mapped(page)) {
> > > + if (folio_anon(folio)) {
> > > + if (folio_mapped(folio)) {
> > > __mod_lruvec_state(from_vec, NR_ANON_MAPPED, -nr_pages);
> > > __mod_lruvec_state(to_vec, NR_ANON_MAPPED, nr_pages);
> > > - if (PageTransHuge(page)) {
> > > + if (folio_multi(folio)) {
> >
> > Shouldn't be folio_transhuge? The resulting code is the same but
> > folio_transhuge is more explicit and matches the THP aspect.
>
> I genuinely don't know. For the benefit of those reading along, the
> important part of the context is:
>
> if (folio_mapped(folio)) {
> __mod_lruvec_state(from_vec, NR_ANON_MAPPED, -nr_pages);
> __mod_lruvec_state(to_vec, NR_ANON_MAPPED, nr_pages);
> if (folio_multi(folio)) {
> __mod_lruvec_state(from_vec, NR_ANON_THPS,
> -nr_pages);
> __mod_lruvec_state(to_vec, NR_ANON_THPS,
> nr_pages);
> }
> }
>
> We need to decide what 'NR_ANON_THPS' means in a folio-based world where
> we have folios of all orders. Does it count only the number of pages
> in folios >= HPAGE_PMD_SIZE? Or does it count the number of pages in
> folios > PAGE_SIZE?
At this stage we only have PMD based, right? I believe it would be
simpler to stick with that at the moment and change that to a more
generic way along with other places which need updating.
Wrt. counters they do count pages so in this case this shouldn't be a
problem. But we do have counters for pmd mappings and that might need
some care.
--
Michal Hocko
SUSE Labs
