From: Johannes Weiner <hannes@cmpxchg.org>
To: Yosry Ahmed <yosryahmed@google.com>
Cc: "Li,Liguang" <liliguang@baidu.com>,
Shakeel Butt <shakeelb@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux-MM <linux-mm@kvack.org>, Cgroups <cgroups@vger.kernel.org>,
Michal Hocko <mhocko@kernel.org>,
Muchun Song <songmuchun@bytedance.com>,
Roman Gushchin <roman.gushchin@linux.dev>
Subject: Re: [PATCH] mm: correctly charge compressed memory to its memcg
Date: Mon, 15 Aug 2022 13:47:15 -0400 [thread overview]
Message-ID: <YvqGoxfs25bEyQGJ@cmpxchg.org> (raw)
In-Reply-To: <CAJD7tkbVz44d64yPm15kUMmpFEQwFtut6Ye8D8oO1jiS9s_tBw@mail.gmail.com>
On Mon, Aug 15, 2022 at 09:16:08AM -0700, Yosry Ahmed wrote:
> On Mon, Aug 15, 2022 at 8:42 AM Yosry Ahmed <yosryahmed@google.com> wrote:
> >
> > On Mon, Aug 15, 2022 at 8:31 AM Johannes Weiner <hannes@cmpxchg.org> wrote:
> > >
> > > On Mon, Aug 15, 2022 at 06:46:46AM -0700, Yosry Ahmed wrote:
> > > > Yeah I understand this much, what I don't understand is why we charge
> > > > the zswap memory through objcg (thus tying it to memcg kmem charging)
> > > > rather than directly through memcg.
> > >
> > > The charged quantities are smaller than a page, so we have to use the
> > > byte interface.
> > >
> > > The byte interface (objcg) was written for slab originally, hence the
> > > link to the kmem option. But note that CONFIG_MEMCG_KMEM is no longer
> > > a user-visible option, and for all intents and purposes a fixed part
> > > of CONFIG_MEMCG.
> > >
> > > (There is the SLOB quirk. But I'm not sure anybody uses slob, let
> > > alone slob + memcg.)
> >
> > Thanks for the clarification, it makes sense to use the byte interface
> > here for this, and thanks for pointing out that CONFIC_MEMCG_KMEM is
> > not part of CONFIG_MEMCG.
> >
> > One more question :) memcg kmem charging can still be disabled even
> > with !CONFIG_MEMCG_KMEM, right? In this case zswap charging will also
> > be off, which seems like an unintended side effect, right?
>
> memcg kmem charging can still be disabled even
> with CONFIG_MEMCG_KMEM***
Yes, indeed, if the host is booted with the nokmem flag. Doing so will
turn off slab, percpu, and (as of recently) zswap.
The zswap backing storage *is* kernel memory, so that seems like the
correct semantics for the flag.
That said, the distinction between kernel and user memory is becoming
increasingly odd. The more kernel memory we track, the more ridiculous
the size of the hole you punch into resource control by disabling it.
Maybe we should just deprecate that knob altogether.
next prev parent reply other threads:[~2022-08-15 17:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220811081913.102770-1-liliguang@baidu.com>
[not found] ` <YvWa9MOQWBICInjO@P9FQF9L96D.corp.robot.car>
2022-08-12 21:56 ` Shakeel Butt
2022-08-13 0:43 ` Yosry Ahmed
2022-08-15 2:52 ` Li,Liguang
2022-08-15 8:09 ` Yosry Ahmed
2022-08-15 11:48 ` Li,Liguang
2022-08-15 13:46 ` Yosry Ahmed
2022-08-15 15:31 ` Johannes Weiner
2022-08-15 15:42 ` Yosry Ahmed
2022-08-15 16:16 ` Yosry Ahmed
2022-08-15 17:47 ` Johannes Weiner [this message]
2022-08-15 17:55 ` Yosry Ahmed
2022-08-16 22:19 ` Shakeel Butt
2022-08-15 6:52 ` Muchun Song
2022-08-15 15:20 ` Johannes Weiner
2022-08-17 17:17 ` Andrew Morton
2022-11-14 19:48 Johannes Weiner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YvqGoxfs25bEyQGJ@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=liliguang@baidu.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=roman.gushchin@linux.dev \
--cc=shakeelb@google.com \
--cc=songmuchun@bytedance.com \
--cc=yosryahmed@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox