On Wed, Jan 13, 2021 at 11:13 AM Shakeel Butt <shake...@google.com> wrote:
>
> On Wed, Jan 13, 2021 at 10:43 AM Roman Gushchin <g...@fb.com> wrote:
> >
> > On Tue, Jan 12, 2021 at 04:18:44PM -0800, Shakeel Butt wrote:
> > > On Tue, Jan 12, 2021 at 4:12 PM Arjun Roy <arjun...@google.com> wrote:
> > > >
> > > > On Tue, Jan 12, 2021 at 3:48 PM Roman Gushchin <g...@fb.com> wrote:
> > > > >
> > > [snip]
> > > > > Historically we have a corresponding vmstat counter to each charged
> > > > > page.
> > > > > It helps with finding accounting/stastistics issues: we can check that
> > > > > memory.current ~= anon + file + sock + slab + percpu + stack.
> > > > > It would be nice to preserve such ability.
> > > > >
> > > >
> > > > Perhaps one option would be to have it count as a file page, or have a
> > > > new category.
> > > >
> > >
> > > Oh these are actually already accounted for in NR_FILE_MAPPED.
> >
> > Well, it's confusing. Can't we fix this by looking at the new page memcg
> > flag?
>
> Yes we can. I am inclined more towards just using NR_FILE_PAGES (as
> Arjun suggested) instead of adding a new metric.
IMHO I tend to agree with Roman, it sounds confusing. I'm not sure how
people relies on the counter to have ballpark estimation about the
amount of reclaimable memory for specific memcg, but they are
unreclaimable. And, I don't think they are accounted to
NR_ACTIVE_FILE/NR_INACTIVE_FILE, right? So, the disparity between
NR_FILE_PAGES and NR_{IN}ACTIVE_FILE may be confusing either.
>
