[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20201130201540.GB1354703@carbon.DHCP.thefacebook.com>
Date: Mon, 30 Nov 2020 12:15:40 -0800
From: Roman Gushchin <guro@...com>
To: Mike Rapoport <rppt@...nel.org>
CC: Shakeel Butt <shakeelb@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Andy Lutomirski <luto@...nel.org>,
Arnd Bergmann <arnd@...db.de>, Borislav Petkov <bp@...en8.de>,
Catalin Marinas <catalin.marinas@....com>,
Christopher Lameter <cl@...ux.com>,
Dan Williams <dan.j.williams@...el.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
David Hildenbrand <david@...hat.com>,
Elena Reshetova <elena.reshetova@...el.com>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
James Bottomley <jejb@...ux.ibm.com>,
"Kirill A. Shutemov" <kirill@...temov.name>,
Matthew Wilcox <willy@...radead.org>,
Mark Rutland <mark.rutland@....com>,
Mike Rapoport <rppt@...ux.ibm.com>,
Michael Kerrisk <mtk.manpages@...il.com>,
Palmer Dabbelt <palmer@...belt.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Peter Zijlstra <peterz@...radead.org>,
Rick Edgecombe <rick.p.edgecombe@...el.com>,
Shuah Khan <shuah@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Tycho Andersen <tycho@...ho.ws>, Will Deacon <will@...nel.org>,
<linux-api@...r.kernel.org>, <linux-arch@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux MM <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>,
<linux-kselftest@...r.kernel.org>, <linux-nvdimm@...ts.01.org>,
<linux-riscv@...ts.infradead.org>, <x86@...nel.org>
Subject: Re: [PATCH v12 07/10] secretmem: add memcg accounting
On Sun, Nov 29, 2020 at 07:26:25PM +0200, Mike Rapoport wrote:
> On Sun, Nov 29, 2020 at 07:53:45AM -0800, Shakeel Butt wrote:
> > On Wed, Nov 25, 2020 at 1:51 AM Mike Rapoport <rppt@...nel.org> wrote:
> > >
> > > From: Mike Rapoport <rppt@...ux.ibm.com>
> > >
> > > Account memory consumed by secretmem to memcg. The accounting is updated
> > > when the memory is actually allocated and freed.
> > >
> > > Signed-off-by: Mike Rapoport <rppt@...ux.ibm.com>
> > > Acked-by: Roman Gushchin <guro@...com>
> > > ---
> > > mm/filemap.c | 3 ++-
> > > mm/secretmem.c | 36 +++++++++++++++++++++++++++++++++++-
> > > 2 files changed, 37 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/mm/filemap.c b/mm/filemap.c
> > > index 249cf489f5df..cf7f1dc9f4b8 100644
> > > --- a/mm/filemap.c
> > > +++ b/mm/filemap.c
> > > @@ -42,6 +42,7 @@
> > > #include <linux/psi.h>
> > > #include <linux/ramfs.h>
> > > #include <linux/page_idle.h>
> > > +#include <linux/secretmem.h>
> > > #include "internal.h"
> > >
> > > #define CREATE_TRACE_POINTS
> > > @@ -844,7 +845,7 @@ static noinline int __add_to_page_cache_locked(struct page *page,
> > > page->mapping = mapping;
> > > page->index = offset;
> > >
> > > - if (!huge) {
> > > + if (!huge && !page_is_secretmem(page)) {
> > > error = mem_cgroup_charge(page, current->mm, gfp);
> > > if (error)
> > > goto error;
> > > diff --git a/mm/secretmem.c b/mm/secretmem.c
> > > index 52a900a135a5..eb6628390444 100644
> > > --- a/mm/secretmem.c
> > > +++ b/mm/secretmem.c
> > > @@ -18,6 +18,7 @@
> > > #include <linux/memblock.h>
> > > #include <linux/pseudo_fs.h>
> > > #include <linux/secretmem.h>
> > > +#include <linux/memcontrol.h>
> > > #include <linux/set_memory.h>
> > > #include <linux/sched/signal.h>
> > >
> > > @@ -44,6 +45,32 @@ struct secretmem_ctx {
> > >
> > > static struct cma *secretmem_cma;
> > >
> > > +static int secretmem_account_pages(struct page *page, gfp_t gfp, int order)
> > > +{
> > > + int err;
> > > +
> > > + err = memcg_kmem_charge_page(page, gfp, order);
> > > + if (err)
> > > + return err;
> > > +
> > > + /*
> > > + * seceremem caches are unreclaimable kernel allocations, so treat
> > > + * them as unreclaimable slab memory for VM statistics purposes
> > > + */
> > > + mod_node_page_state(page_pgdat(page), NR_SLAB_UNRECLAIMABLE_B,
> > > + PAGE_SIZE << order);
> >
> > Please use mod_lruvec_page_state() instead, so we get the memcg stats too.
>
> Ok
>
> > BTW I think secretmem deserves a vmstat entry instead of overloading
> > NR_SLAB_UNRECLAIMABLE_B.
>
> I'd prefer to wait with a dedicated vmstat for now. We can always add it
> later, once we have better picture of secremem usage.
+1 here.
>From what I understand it's not clear now how big typical secret areas will be.
If there will be few 2Mb areas per container (like for storing some keys),
IMO it doesn't justify adding a separate counter. If they will be measured
in GBs, then we'll add it later.
Thanks!
Powered by blists - more mailing lists