On Thu, Nov 02, 2023 at 01:27:24PM -0700, Yosry Ahmed wrote:
> On Thu, Nov 2, 2023 at 1:02 PM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
> > @@ -201,6 +201,12 @@ int swap_writepage(struct page *page, struct writeback_control *wbc)
> > folio_end_writeback(folio);
> > return 0;
> > }
> > +
> > + if (!mem_cgroup_zswap_writeback_enabled(folio_memcg(folio))) {
> > + folio_mark_dirty(folio);
> > + return AOP_WRITEPAGE_ACTIVATE;
> > + }
> > +
>
> I am not a fan of this, because it will disable using disk swap if
> "zswap_writeback" is disabled, even if zswap is disabled or the page
> was never in zswap. The term zswap_writeback makes no sense here tbh.
>
> I am still hoping someone else will suggest better semantics, because
> honestly I can't think of anything. Perhaps something like
> memory.swap.zswap_only or memory.swap.types which accepts a string
> (e.g. "zswap"/"all",..).
I had suggested the writeback name.
My thinking was this: from a user pov, the way zswap is presented and
described, is a fast writeback cache that sits on top of swap. It's
implemented as this lookaside thing right now, but that's never how it
was sold. And frankly, that's not how it's expected to work, either.
>From the docs:
Zswap is a lightweight compressed cache for swap pages.
Zswap evicts pages from compressed cache on an LRU basis to the
backing swap device when the compressed pool reaches its size limit.
When zswap is enabled, IO to the swap device is expected to come from
zswap. Everything else would be a cache failure. There are a few cases
now where zswap rejects and bypasses to swap. It's not a stretch to
call them accelerated writeback or writethrough. But also, these
represent failures and LRU inversions, we're working on fixing them.
So from a user POV it's reasonable to say if I have zswap enabled and
disable writeback, I don't expect swapfile IO.
But yes, if zswap isn't enabled at all, this shouldn't prevent pages
from going to swap.
