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@xxxxxxxxxx> wrote: > > > > On Mon, Aug 15, 2022 at 8:31 AM Johannes Weiner <hannes@xxxxxxxxxxx> 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.
