On Wed 30-10-24 16:43:42, Joshua Hahn wrote: > On Wed, Oct 30, 2024 at 2:30 PM Johannes Weiner <hannes@xxxxxxxxxxx> wrote: > > > > Joshua, can you please include something like this at the end: > > > > lruvec_stat_mod_folio() keys off of folio->memcg linkage, which is > > only set up if CGRP_ROOT_MEMORY_HUGETLB_ACCOUNTING is switched > > on. This ensures that memory.stat::hugetlb is in sync with the hugetlb > > share of memory.current. > > Hello Andrew, > > I saw that it was merged into mm-unstable earlier yesterday. Would it > be possible > to add this block of text to the patch description right before the footnotes? > > 3. Implementation Details: > In the alloc / free hugetlb functions, we call lruvec_stat_mod_folio > regardless of whether memcg accounts hugetlb. lruvec_stat_mod_folio > keys off of folio->memcg which is only set up if the > CGRP_ROOT_MEMORY_HUGETLB_ACCOUTING cgroup mount option is used, so > it will not try to accumulate hugetlb unless the flag is set. Thanks for the update and sorry for being pitbull here but this is is a bit confusing. Let me try to reformulate as per my understanding In the alloc / free hugetlb functions, we call lruvec_stat_mod_folio regardless of whether memcg accounts hugetlb. mem_cgroup_commit_charge called from alloc_hugetlb_folio will set memcg for folio only if CGRP_ROOT_MEMORY_HUGETLB_ACCOUTING is enabled so lruvec_stat_mod_folio accounts per memcg hugetlb counter only if the feature is enabled. Regardless of the memcg accounting, though, the newly added global counter is updated and shown in /proc/vmstat. I would also add the following The global counter is added because vmstats is the preferred framework for cgroup stats. It makes stat items consistent between global and cgroup. It provides a per-node breakdown as well which is useful. It avoids proliferating cgroup-specific hooks in generic MM code. I will leave up to you whether to add above paragraphs but I believe they clarify the intention and the implementation. Acked-by: Michal Hocko <mhocko@xxxxxxxx> Thanks! -- Michal Hocko SUSE Labs
