Re: [PATCH 2/3] mm/zswap: Implement proactive writeback

[Yosry Ahmed]

> > Zswap objects are organized into LRU and exposed to the shrinker
> > interface. Echo-ing to memory.reclaim should also offload some zswap
> > entries, correct? Are there still cold zswap entries that escape this,
> > somehow?
> >
>
> Yes, the memory.reclaim path does drive some zswap writeback, but
> it is not enough for our case.
>
> 1. For a memcg that has reached steady state (a common case being
> when memory.current is below the policy target), the userspace
> reclaimer may not invoke memory.reclaim on it for a long time,
> and so no second-level offloading happens through
> memory.reclaim. In this state we want
> memory.zswap.proactive_writeback to write back entries that
> have sat in zswap past an age threshold, to further reclaim
> the DRAM still held by the compressed data.
>
> 2. Even when memory.reclaim is running, the fraction of zswap
> residency that ends up reaching the backing swap device is
> still very small for many of our workloads, and the userspace
> reclaimer has no way to participate in or control the
> granularity of zswap writeback. So in our deployment we prefer
> to leave the zswap shrinker disabled, decouple LRU -> zswap
> from zswap -> swap, and use a dedicated proactive-writeback
> interface that lifts the writeback policy into userspace where
> it can evolve independently of the kernel.

To be honest I see the point of proactively reclaiming compressed
memory in zswap. If you use memory.reclaim, you are also reclaiming
hotter memory in the process, and you are not necessarily getting as
much writeback as you want. The memory in zswap is a more conservative
choice for proactive reclaim because it's memory that's guaranteed to
be cold(ish) and not being accessed.

That being said, the interface is not great any way you cut it :/

I don't like the 'memory.zswap.proactive_writeback' name, maybe we can
stay consistent by doing 'memory.zswap.reclaim', but that just as
easily reads as "reclaim using zswap". Maybe
'memory.zswap.do_writeback' or something, idk.

I also don't like having two proactive reclaim interfaces, so a voice
in my head wants to tie this into 'memory.reclaim' somehow, but that
includes adding a pretty specific argument (e.g. 'memory.reclaim
zswap_writeback_only=1'.

I don't like any of these options, and we also need to consider what
the memcg maintainers think. I see the use case of proactive writeback
but I am struggling to come up with a clean interface.

I also think we should take the 'age' aspect out of the conversation
for now, it can be a separate discussion. Well, unless we decide to
tie it to memory.reclaim. If memory.reclaim broadly supports age-based
reclaim then zswap writeback can be a natural part of that without
requiring a specific interface.