Re: [PATCH v3 14/18] mm/memcg: Convert mem_cgroup_move_account() to use a folio
From: Matthew Wilcox <hidden>
Date: 2021-06-30 11:23:13
Also in:
linux-mm
On Wed, Jun 30, 2021 at 10:30:38AM +0200, Michal Hocko wrote:
quoted
- 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?
Similar question (and I suspect the same answer) for NR_SHMEM_THPS and
NR_FILE_THPS. Right now, I've been accounting any multi-page folio as
a THP, but I don't have a good sense of what the answer should be.