Re: [swap tier discussion] Re: [PATCH v3 2/4] mm/zswap: Implement proactive writeback
From: Yosry Ahmed
Date: Fri Jun 12 2026 - 17:32:07 EST
> > > Is Hao's work needed for some followup work/development? The earliest Hao's
> > > work can is 7.3, so if we aim to figure out swap tiering interfaces in next
> > > couple of weeks then option 3 is the way to go. If swap tiers take more time
> > > then we can discuss other options as well.
> > > However I would need zswap folks (Yosry & Nhat) help in figuring out swap tiers
> > > interfaces. Zswap is the current top tier swap usage in real world. I want
> > > zswap users to eaily (and hopefully transparently) migrate to swap tiers.
> >
> > I am looking forward to the discussion on this interface!
> >
> > To help boost the discussion and progress, I would like to share a few of my thoughts.
> > We could either introduce a new interface to trigger demotion/promotion,
> > or we could reuse the existing one (using tier just internally)
> >
> > Based on the memcg interface currently proposed in swap_tier
> > (memory.swap.tiers, memory.swap.tiers.effective), I think it aligns well
> > with the current direction. It provides a foundation for selectively
> > targeting devices in tier order.
>
> Here instead of cpuset like interface, we may want more zswap like interface
> where you can put limit on the usage i.e. memory.swap.tier*.max. We can start
> with allowing only two values i.e. 0 and max which effectively will be the
> same as what you need.
>
> I will respond to your other points later when I have time.
If we will have one interface for all the tiers for memory tiering,
I'd rather we do the swap for swap tiering. So maybe
memory.swap.tiers.max or memory.swap.tiered max?
The file can show the limits for all tiers when read, and maybe write
something like "echo 'tierX max' > memory.swap.tiers.max" to it to set
a new limit. We can support only 0/max for now to enable/disable
tiers. In the future, we can also allow something like "auto" to
automatically scale the limit based on the swapfile size and
memory.swap.max, similar to the direction memory tiering is heading
in.
I think we can start with just this interface for now, and expand
incrementally. For proactive zswap writeback, we can add
memory.swap.tiers.demote or something, and only support zswap
initially?