mm/zswap: Implement per-cgroup proactive writeback

From: Hao Jia <[email protected]>

The zswap background writeback worker shrink_worker() uses a global cursor zswap_next_shrink, protected by zswap_shrink_lock, to round-robin across the online memcgs under root_mem_cgroup.

Proactive writeback also wants a similar per-memcg cursor that is scoped to the specified memcg, so that repeated invocations against the same memcg make forward progress across its descendant memcgs instead of restarting from the first child memcg each time.

Naturally, group the cursor and its protecting spinlock into a zswap_wb_iter struct, and make it a member of struct mem_cgroup to realize per-memcg cursor management. Accordingly, shrink_worker() now uses the lock and cursor in root_mem_cgroup->zswap_wb_iter.

Because the cursor is now per-memcg, the offline cleanup must visit every ancestor that could be holding a reference to the dying memcg. Factor out __zswap_memcg_offline_cleanup() and walk from dead_memcg up to the root.

No functional change intended for shrink_worker().

From: Hao Jia <[email protected]>

The zswap background writeback worker shrink_worker() uses a global cursor zswap_next_shrink, protected by zswap_shrink_lock, to round-robin across the online memcgs under root_mem_cgroup.

Proactive writeback also wants a similar per-memcg cursor that is scoped to the specified memcg, so that repeated invocations against the same memcg make forward progress across its descendant memcgs instead of restarting from the first child memcg each time.

Naturally, group the cursor and its protecting spinlock into a zswap_wb_iter struct, and make it a member of struct mem_cgroup to realize per-memcg cursor management. Accordingly, shrink_worker() now uses the lock and cursor in root_mem_cgroup->zswap_wb_iter.

Because the cursor is now per-memcg, the offline cleanup must visit every ancestor that could be holding a reference to the dying memcg. Factor out __zswap_memcg_offline_cleanup() and walk from dead_memcg up to the root.

Quoted 10 lines · Hao Jia

From: Hao Jia <[email protected]>

The zswap background writeback worker shrink_worker() uses a global cursor zswap_next_shrink, protected by zswap_shrink_lock, to round-robin across the online memcgs under root_mem_cgroup.

Proactive writeback also wants a similar per-memcg cursor that is scoped to the specified memcg, so that repeated invocations against the same memcg make forward progress across its descendant memcgs instead of restarting from the first child memcg each time.

Is this a problem in practice?

Is the concern the overhead of scanning memcgs repeatedly, or lack of fairness? I wonder if we should just do writeback in batches from all memcgs, similar to how reclaim does it, then evaluate at the end if we need to start over?

Quoted 5 lines

Naturally, group the cursor and its protecting spinlock into a zswap_wb_iter struct, and make it a member of struct mem_cgroup to realize per-memcg cursor management. Accordingly, shrink_worker() now uses the lock and cursor in root_mem_cgroup->zswap_wb_iter.

If we really need to have per-memcg cursors (I am not a big fan), I think we can minimize the overhead by making the cursor updates use atomic cmpxchg instead of having a per-memcg lock.

Quoted 5 lines

Because the cursor is now per-memcg, the offline cleanup must visit every ancestor that could be holding a reference to the dying memcg. Factor out __zswap_memcg_offline_cleanup() and walk from dead_memcg up to the root.

Another reason why I don't like per-memcg cursors. There is too much complexity and I wonder if it's warranted. If we stick with per-memcg cursors please do the refactoring in separate patches to make the patches easier to review.

Quoted 12 lines · Yosry Ahmed

Quoted 10 lines · Hao Jia

From: Hao Jia <[email protected]>

The zswap background writeback worker shrink_worker() uses a global cursor zswap_next_shrink, protected by zswap_shrink_lock, to round-robin across the online memcgs under root_mem_cgroup.

Proactive writeback also wants a similar per-memcg cursor that is scoped to the specified memcg, so that repeated invocations against the same memcg make forward progress across its descendant memcgs instead of restarting from the first child memcg each time.

Quoted 7 lines

Is this a problem in practice?

Is the concern the overhead of scanning memcgs repeatedly, or lack of fairness? I wonder if we should just do writeback in batches from all memcgs, similar to how reclaim does it, then evaluate at the end if we need to start over?

Not using a per-cgroup cursor will cause issues for "repeated small-budget calls" cases. For example, repeatedly triggering a 2MB writeback might result in only writing back pages from the first few child memcgs every time. In the worst-case scenario (where the writeback amount is less than WB_BATCH), it might only ever write back from the first child memcg.

Similar to how memory reclaim uses mem_cgroup_iter() (via struct mem_cgroup_reclaim_iter) and the old shrink_worker() used zswap_next_shrink, we need a shared cursor here.

Quoted 10 lines

Quoted 5 lines

Naturally, group the cursor and its protecting spinlock into a zswap_wb_iter struct, and make it a member of struct mem_cgroup to realize per-memcg cursor management. Accordingly, shrink_worker() now uses the lock and cursor in root_mem_cgroup->zswap_wb_iter.

If we really need to have per-memcg cursors (I am not a big fan), I think we can minimize the overhead by making the cursor updates use atomic cmpxchg instead of having a per-memcg lock.

Because mem_cgroup_iter() always calls css_put(&prev->css), we cannot simply update zswap_wb_iter.pos via cmpxchg() after calling it. Doing so could lead to a double css_put() issue on prev->css.

Therefore, if we switch to the cmpxchg() approach, we wouldn't be able to reuse the existing mem_cgroup_iter() logic. We would have to write a new function similar to cgroup_iter(), and its implementation might end up looking a bit obscure/complex.

Currently, this lock is only used in shrink_memcg(), proactive writeback, and mem_cgroup_css_offline(). Note that shrink_memcg() only acquires the lock of the root cgroup, and mem_cgroup_css_offline() is unlikely to be a hot path.

So, should we keep the spin_lock or go with the cmpxchg() approach? Yosry and Nhat, what are your thoughts on this?

TBH, I think the spinlock is simpler at this point if we need to do all of this explanation to justify correctness of cmpxchg :)

That said, if memcg folks feel like an extra spinlock per cgroup is a bit much, we can go with the cmpxchg() approach. Please include a FAT comment explains the compxchg() approach's nuance in the code though. Speaking from experience, I will forget why it is correct 2 months after the patch lands :)

Quoted 12 lines · Yosry Ahmed

Quoted 10 lines · Hao Jia

From: Hao Jia <[email protected]>

The zswap background writeback worker shrink_worker() uses a global cursor zswap_next_shrink, protected by zswap_shrink_lock, to round-robin across the online memcgs under root_mem_cgroup.

Proactive writeback also wants a similar per-memcg cursor that is scoped to the specified memcg, so that repeated invocations against the same memcg make forward progress across its descendant memcgs instead of restarting from the first child memcg each time.

Quoted 7 lines

Is this a problem in practice?

Is the concern the overhead of scanning memcgs repeatedly, or lack of fairness? I wonder if we should just do writeback in batches from all memcgs, similar to how reclaim does it, then evaluate at the end if we need to start over?

Not using a per-cgroup cursor will cause issues for "repeated small-budget calls" cases. For example, repeatedly triggering a 2MB writeback might result in only writing back pages from the first few child memcgs every time. In the worst-case scenario (where the writeback amount is less than WB_BATCH), it might only ever write back from the first child memcg.

Similar to how memory reclaim uses mem_cgroup_iter() (via struct mem_cgroup_reclaim_iter) and the old shrink_worker() used zswap_next_shrink, we need a shared cursor here.

Quoted 31 lines · Hao Jia

Quoted 12 lines · Yosry Ahmed

Quoted 10 lines · Hao Jia

From: Hao Jia <[email protected]>

The zswap background writeback worker shrink_worker() uses a global cursor zswap_next_shrink, protected by zswap_shrink_lock, to round-robin across the online memcgs under root_mem_cgroup.

Proactive writeback also wants a similar per-memcg cursor that is scoped to the specified memcg, so that repeated invocations against the same memcg make forward progress across its descendant memcgs instead of restarting from the first child memcg each time.

Quoted 7 lines

Is this a problem in practice?

Is the concern the overhead of scanning memcgs repeatedly, or lack of fairness? I wonder if we should just do writeback in batches from all memcgs, similar to how reclaim does it, then evaluate at the end if we need to start over?

Not using a per-cgroup cursor will cause issues for "repeated small-budget calls" cases. For example, repeatedly triggering a 2MB writeback might result in only writing back pages from the first few child memcgs every time. In the worst-case scenario (where the writeback amount is less than WB_BATCH), it might only ever write back from the first child memcg.

Quoted 3 lines

Similar to how memory reclaim uses mem_cgroup_iter() (via struct mem_cgroup_reclaim_iter) and the old shrink_worker() used zswap_next_shrink, we need a shared cursor here.

I think each proactive reclaim invocation just walk the entire subtree for page reclaim right (see shrink_node_memcgs())? Would that be acceptable for you?

I also wonder if we can at least make this structure dynamically allocated... In a system, you only really invoke proactive reclaim against a few target cgroups, no?

Quoted 12 lines · Yosry Ahmed

Quoted 10 lines · Hao Jia

From: Hao Jia <[email protected]>

The zswap background writeback worker shrink_worker() uses a global cursor zswap_next_shrink, protected by zswap_shrink_lock, to round-robin across the online memcgs under root_mem_cgroup.

Proactive writeback also wants a similar per-memcg cursor that is scoped to the specified memcg, so that repeated invocations against the same memcg make forward progress across its descendant memcgs instead of restarting from the first child memcg each time.

Quoted 7 lines

Is this a problem in practice?

Is the concern the overhead of scanning memcgs repeatedly, or lack of fairness? I wonder if we should just do writeback in batches from all memcgs, similar to how reclaim does it, then evaluate at the end if we need to start over?

Not using a per-cgroup cursor will cause issues for "repeated small-budget calls" cases. For example, repeatedly triggering a 2MB writeback might result in only writing back pages from the first few child memcgs every time. In the worst-case scenario (where the writeback amount is less than WB_BATCH), it might only ever write back from the first child memcg.

Similar to how memory reclaim uses mem_cgroup_iter() (via struct mem_cgroup_reclaim_iter) and the old shrink_worker() used zswap_next_shrink, we need a shared cursor here.

Quoted 12 lines

Quoted 7 lines

Naturally, group the cursor and its protecting spinlock into a zswap_wb_iter struct, and make it a member of struct mem_cgroup to realize per-memcg cursor management. Accordingly, shrink_worker() now uses the lock and cursor in root_mem_cgroup->zswap_wb_iter.

If we really need to have per-memcg cursors (I am not a big fan), I think we can minimize the overhead by making the cursor updates use atomic cmpxchg instead of having a per-memcg lock.

Because mem_cgroup_iter() always calls css_put(&prev->css), we cannot simply update zswap_wb_iter.pos via cmpxchg() after calling it. Doing so could lead to a double css_put() issue on prev->css.

Therefore, if we switch to the cmpxchg() approach, we wouldn't be able to reuse the existing mem_cgroup_iter() logic. We would have to write a new function similar to cgroup_iter(), and its implementation might end up looking a bit obscure/complex.

Currently, this lock is only used in shrink_memcg(), proactive writeback, and mem_cgroup_css_offline(). Note that shrink_memcg() only acquires the lock of the root cgroup, and mem_cgroup_css_offline() is unlikely to be a hot path.

So, should we keep the spin_lock or go with the cmpxchg() approach? Yosry and Nhat, what are your thoughts on this?

Quoted 9 lines

Quoted 8 lines

Because the cursor is now per-memcg, the offline cleanup must visit every ancestor that could be holding a reference to the dying memcg. Factor out __zswap_memcg_offline_cleanup() and walk from dead_memcg up to the root.

Quoted 4 lines

Another reason why I don't like per-memcg cursors. There is too much complexity and I wonder if it's warranted. If we stick with per-memcg cursors please do the refactoring in separate patches to make the patches easier to review.

Sorry about that. I will try to keep each patch as simple as possible in the next version.

Thanks,
Hao

Quoted 23 lines · Hao Jia

Quoted 12 lines · Yosry Ahmed

Quoted 10 lines · Hao Jia

From: Hao Jia <[email protected]>

The zswap background writeback worker shrink_worker() uses a global cursor zswap_next_shrink, protected by zswap_shrink_lock, to round-robin across the online memcgs under root_mem_cgroup.

Proactive writeback also wants a similar per-memcg cursor that is scoped to the specified memcg, so that repeated invocations against the same memcg make forward progress across its descendant memcgs instead of restarting from the first child memcg each time.

Quoted 7 lines

Is this a problem in practice?

Is the concern the overhead of scanning memcgs repeatedly, or lack of fairness? I wonder if we should just do writeback in batches from all memcgs, similar to how reclaim does it, then evaluate at the end if we need to start over?

Quoted 5 lines

Not using a per-cgroup cursor will cause issues for "repeated small-budget calls" cases. For example, repeatedly triggering a 2MB writeback might result in only writing back pages from the first few child memcgs every time. In the worst-case scenario (where the writeback amount is less than WB_BATCH), it might only ever write back from the first child memcg.

Right, so a fairness concern?

I wonder if we should just reclaim a batch from each memcg, then check if we reached the goal, otherwise start over. If the batch size is small enough that should work?

Quoted 5 lines

Similar to how memory reclaim uses mem_cgroup_iter() (via struct mem_cgroup_reclaim_iter) and the old shrink_worker() used zswap_next_shrink, we need a shared cursor here.

Right, I understand that in theory we need a cursor. I am just wondering if the complexity is justified in practice. Reclaim is a much larger beast than zswap writeback. I wonder if we can just get away with scanning a batch from each child memcg -- for per-memcg reclaim, not global.

We can always improve it later with a cursor if there's an actual need.

Quoted 13 lines

Quoted 12 lines

Quoted 7 lines

Naturally, group the cursor and its protecting spinlock into a zswap_wb_iter struct, and make it a member of struct mem_cgroup to realize per-memcg cursor management. Accordingly, shrink_worker() now uses the lock and cursor in root_mem_cgroup->zswap_wb_iter.

If we really need to have per-memcg cursors (I am not a big fan), I think we can minimize the overhead by making the cursor updates use atomic cmpxchg instead of having a per-memcg lock.

Quoted 8 lines

Because mem_cgroup_iter() always calls css_put(&prev->css), we cannot simply update zswap_wb_iter.pos via cmpxchg() after calling it. Doing so could lead to a double css_put() issue on prev->css.

Therefore, if we switch to the cmpxchg() approach, we wouldn't be able to reuse the existing mem_cgroup_iter() logic. We would have to write a new function similar to cgroup_iter(), and its implementation might end up looking a bit obscure/complex.

What if we do something like this (for the global cursor):

	do {
		memcg = xchg(zswap_next_shrink, NULL);
		memcg = mem_cgroup_iter(NULL, memcg, NULL);
		/* If the cursor was advanced from under us, try again */
		if (!try_cmpxchg(zswap_next_shrink, NULL, memcg))
			continue;
	} while (..);

There is a window where a racing shrinker will see the cursor as NULL and start over, but that should be fine. We can generalize this for the per-memcg cursor.

That being said..

Quoted 5 lines

Currently, this lock is only used in shrink_memcg(), proactive writeback, and mem_cgroup_css_offline(). Note that shrink_memcg() only acquires the lock of the root cgroup, and mem_cgroup_css_offline() is unlikely to be a hot path.

..this made me realize it's probably fine to just use a global lock for now?

IIUC the only additional contention to the existing lock will be from userspace proactive writeback, and that shouldn't be a big deal especially with the critical section being short?

Quoted 3 lines

So, should we keep the spin_lock or go with the cmpxchg() approach? Yosry and Nhat, what are your thoughts on this?

I think we should experiment with the global lock first. See if you observe any regressions with workloads that put a lot of pressure on the lock (a lot of threads in reclaim doing writeback + a few userspace threads doing proactive writeback). See if the userspace threads actually cause a meaningful regression.

Quoted 21 lines

Quoted 13 lines

Quoted 5 lines

Quoted 4 lines

Proactive writeback also wants a similar per-memcg cursor that is scoped to the specified memcg, so that repeated invocations against the same memcg make forward progress across its descendant memcgs instead of restarting from the first child memcg each time.

Quoted 7 lines

Is this a problem in practice?

Is the concern the overhead of scanning memcgs repeatedly, or lack of fairness? I wonder if we should just do writeback in batches from all memcgs, similar to how reclaim does it, then evaluate at the end if we need to start over?

Quoted 5 lines

Not using a per-cgroup cursor will cause issues for "repeated small-budget calls" cases. For example, repeatedly triggering a 2MB writeback might result in only writing back pages from the first few child memcgs every time. In the worst-case scenario (where the writeback amount is less than WB_BATCH), it might only ever write back from the first child memcg.

Right, so a fairness concern?

Quoted 3 lines

I wonder if we should just reclaim a batch from each memcg, then check if we reached the goal, otherwise start over. If the batch size is small enough that should work?

Even with a small batch size, for small writeback requests triggered by user-space (e.g., 2MB, which is batch size * N), it might still repeatedly write back from only the first N child memcgs.

This could cause the user-space agent to prematurely give up on zswap writeback.

Quoted 11 lines

What if we do something like this (for the global cursor):

	do {
		memcg = xchg(zswap_next_shrink, NULL);
		memcg = mem_cgroup_iter(NULL, memcg, NULL);
		/* If the cursor was advanced from under us, try again */
		if (!try_cmpxchg(zswap_next_shrink, NULL, memcg))
			continue;
	} while (..);

Regarding the code above, IIRC, both the global and per-cgroup cursors suffer from race conditions. This race can cause mem_cgroup_iter(NULL, NULL, NULL) to return the root memcg or its descendants, leading zswap to write back pages from the wrong memcg.

Additionally, since mem_cgroup_iter() puts the prev memcg ref and gets the next memcg ref, a try_cmpxchg() failure on CPU1 might also lead to a ref leak for memcg1.

CPU1 CPU2
memcg1 = xchg(pos, NULL)

                               memcg2 = xchg(pos, NULL) memcg2 = NULL;

memcg1 = mem_cgroup_iter()
mem_cgroup_iter(NULL, **NULL**, NULL) error memcg
try_cmpxchg(pos，NULL，memcg2） succeed
try_cmpxchg(pos，NULL，memcg1） **fail**

I took a stab at implementing a cmpxchg()-based zswap_mem_cgroup_iter() modeled after mem_cgroup_iter(), and it actually doesn't look that complex after all :)

Quoted 12 lines

There is a window where a racing shrinker will see the cursor as NULL and start over, but that should be fine. We can generalize this for the per-memcg cursor.

That being said..

Quoted 5 lines

Currently, this lock is only used in shrink_memcg(), proactive writeback, and mem_cgroup_css_offline(). Note that shrink_memcg() only acquires the lock of the root cgroup, and mem_cgroup_css_offline() is unlikely to be a hot path.

Quoted 7 lines

..this made me realize it's probably fine to just use a global lock for now?

IIUC the only additional contention to the existing lock will be from userspace proactive writeback, and that shouldn't be a big deal especially with the critical section being short?

In the current patch implementation, this lock protects the cgroup's own cursor variable. During each writeback, we only acquire the spin_lock of the target cgroup itself; we do not attempt to **spin on any child cgroup's lock while iterating through the descendants**.

Quoted 11 lines

Quoted 5 lines

So, should we keep the spin_lock or go with the cmpxchg() approach? Yosry and Nhat, what are your thoughts on this?

I think we should experiment with the global lock first. See if you observe any regressions with workloads that put a lot of pressure on the lock (a lot of threads in reclaim doing writeback + a few userspace threads doing proactive writeback). See if the userspace threads actually cause a meaningful regression.

Sorry, it seems there are some implementation issues with the global lock approach.

In practice, our user-space agent mostly operates in the following two scenarios:
- Triggering proactive writeback on the same cgroup at different times
(sequentially).
- Triggering proactive writeback on different cgroups at the same time
(concurrently).

In both cases, there is no lock contention. So, the current lock works perfectly fine for us.

However, if we really hate zswap_wb_iter.lock, I can try replacing it with the cmpxchg() approach.

Thanks,
Hao

Quoted 21 lines

Quoted 21 lines

Quoted 13 lines

Quoted 5 lines

Quoted 4 lines

Proactive writeback also wants a similar per-memcg cursor that is scoped to the specified memcg, so that repeated invocations against the same memcg make forward progress across its descendant memcgs instead of restarting from the first child memcg each time.

Quoted 7 lines

Is this a problem in practice?

Is the concern the overhead of scanning memcgs repeatedly, or lack of fairness? I wonder if we should just do writeback in batches from all memcgs, similar to how reclaim does it, then evaluate at the end if we need to start over?

Quoted 5 lines

Not using a per-cgroup cursor will cause issues for "repeated small-budget calls" cases. For example, repeatedly triggering a 2MB writeback might result in only writing back pages from the first few child memcgs every time. In the worst-case scenario (where the writeback amount is less than WB_BATCH), it might only ever write back from the first child memcg.

Right, so a fairness concern?

Quoted 7 lines

Quoted 3 lines

I wonder if we should just reclaim a batch from each memcg, then check if we reached the goal, otherwise start over. If the batch size is small enough that should work?

Even with a small batch size, for small writeback requests triggered by user-space (e.g., 2MB, which is batch size * N), it might still repeatedly write back from only the first N child memcgs.

Yes, I understand, I am asking if this is a problem in practice. For this to be a problem we'd need to trigger small writeback requests and have many memcgs.

Quoted 2 lines

This could cause the user-space agent to prematurely give up on zswap writeback.

Why? The kernel should not return before trying to writeback from all memcgs. If we scan the first N child memcgs and did not writeback enough, we should keep going, right?

Quoted 12 lines

Quoted 11 lines

What if we do something like this (for the global cursor):

	do {
		memcg = xchg(zswap_next_shrink, NULL);
		memcg = mem_cgroup_iter(NULL, memcg, NULL);
		/* If the cursor was advanced from under us, try again */
		if (!try_cmpxchg(zswap_next_shrink, NULL, memcg))
			continue;
	} while (..);

Quoted 4 lines

Regarding the code above, IIRC, both the global and per-cgroup cursors suffer from race conditions. This race can cause mem_cgroup_iter(NULL, NULL, NULL) to return the root memcg or its descendants, leading zswap to write back pages from the wrong memcg.

Not the wrong memcg, it will just go back to the first memcg again, which should be fine as I mentioned below.

Quoted 6 lines

Additionally, since mem_cgroup_iter() puts the prev memcg ref and gets the next memcg ref, a try_cmpxchg() failure on CPU1 might also lead to a ref leak for memcg1.

Quoted 8 lines

CPU1 CPU2
memcg1 = xchg(pos, NULL)

                                memcg2 = xchg(pos, NULL) memcg2 = NULL;

memcg1 = mem_cgroup_iter()
mem_cgroup_iter(NULL, **NULL**, NULL) error memcg
try_cmpxchg(pos，NULL，memcg2） succeed
try_cmpxchg(pos，NULL，memcg1） **fail**

Yes, we can probably just take a ref on the memcg before calling mem_cgroup_iter(). That being said, I think we can just keep the lock, see below.

Quoted 4 lines

I took a stab at implementing a cmpxchg()-based zswap_mem_cgroup_iter() modeled after mem_cgroup_iter(), and it actually doesn't look that complex after all :)

I don't think we should re-implement mem_cgroup_iter() here.

[..]

Quoted 20 lines

Quoted 12 lines

There is a window where a racing shrinker will see the cursor as NULL and start over, but that should be fine. We can generalize this for the per-memcg cursor.

That being said..

Quoted 5 lines

Currently, this lock is only used in shrink_memcg(), proactive writeback, and mem_cgroup_css_offline(). Note that shrink_memcg() only acquires the lock of the root cgroup, and mem_cgroup_css_offline() is unlikely to be a hot path.

Quoted 7 lines

..this made me realize it's probably fine to just use a global lock for now?

IIUC the only additional contention to the existing lock will be from userspace proactive writeback, and that shouldn't be a big deal especially with the critical section being short?

Quoted 4 lines

In the current patch implementation, this lock protects the cgroup's own cursor variable. During each writeback, we only acquire the spin_lock of the target cgroup itself; we do not attempt to **spin on any child cgroup's lock while iterating through the descendants**.

Oh, I did not say anything about the current patch adding contention. I am suggesting we just keep using the global lock for the per-memcg cursors, if we keep them.

Right now, without this series, the global lock protects against concurrent changes to the global cursor from concurrent shrinkers. After the series, the only added contenders are userspace proactive writeback threads. Unless you have 10s or 100s of those, it should be fine to keep a single global lock, right?

Yes, userspace can affect writeback efficiency, but we can split the lock when it actually causes a problem.

Quoted 23 lines

Quoted 4 lines

Quoted 4 lines

Quoted 8 lines

Quoted 2 lines

So, should we keep the spin_lock or go with the cmpxchg() approach? Yosry and Nhat, what are your thoughts on this?

I think we should experiment with the global lock first. See if you observe any regressions with workloads that put a lot of pressure on the lock (a lot of threads in reclaim doing writeback + a few userspace threads doing proactive writeback). See if the userspace threads actually cause a meaningful regression.

Sorry, it seems there are some implementation issues with the global lock approach.

In practice, our user-space agent mostly operates in the following two scenarios:
- Triggering proactive writeback on the same cgroup at different times
(sequentially).
- Triggering proactive writeback on different cgroups at the same time
(concurrently).

Quoted 2 lines

In both cases, there is no lock contention. So, the current lock works perfectly fine for us.

Would using the existing global lock work for your use case? How many different cgroups can you end up reclaiming from concurrently?

Quoted 33 lines · Yosry Ahmed

Quoted 21 lines

Quoted 21 lines

Quoted 13 lines

Quoted 5 lines

Quoted 4 lines

Proactive writeback also wants a similar per-memcg cursor that is scoped to the specified memcg, so that repeated invocations against the same memcg make forward progress across its descendant memcgs instead of restarting from the first child memcg each time.

Quoted 7 lines

Is this a problem in practice?

Is the concern the overhead of scanning memcgs repeatedly, or lack of fairness? I wonder if we should just do writeback in batches from all memcgs, similar to how reclaim does it, then evaluate at the end if we need to start over?

Quoted 5 lines

Not using a per-cgroup cursor will cause issues for "repeated small-budget calls" cases. For example, repeatedly triggering a 2MB writeback might result in only writing back pages from the first few child memcgs every time. In the worst-case scenario (where the writeback amount is less than WB_BATCH), it might only ever write back from the first child memcg.

Right, so a fairness concern?

Quoted 7 lines

Quoted 3 lines

I wonder if we should just reclaim a batch from each memcg, then check if we reached the goal, otherwise start over. If the batch size is small enough that should work?

Even with a small batch size, for small writeback requests triggered by user-space (e.g., 2MB, which is batch size * N), it might still repeatedly write back from only the first N child memcgs.

Yes, I understand, I am asking if this is a problem in practice. For this to be a problem we'd need to trigger small writeback requests and have many memcgs.

Quoted 7 lines

Quoted 2 lines

This could cause the user-space agent to prematurely give up on zswap writeback.

Why? The kernel should not return before trying to writeback from all memcgs. If we scan the first N child memcgs and did not writeback enough, we should keep going, right?

Yes, this issue is not caused by the kernel, but rather by our user-space agent itself.

For instance, suppose a parent memcg has two children, memcg1 and memcg2, each with 200MB of zswap (100MB inactive). Triggering proactive writeback on the parent memcg will exhaust memcg1's inactive zswap pages. After that, even though memcg2 still has plenty of inactive zswap pages, it will continue to write back memcg1's active zswap pages. Writing back active zswap pages causes the user-space agent to prematurely abort the writeback because it detects that certain memcg metrics have exceeded predefined thresholds.

Of course, real-world scenarios are much more complex, and this kind of case is extremely rare in our environment.

That being said, your suggestion of using the global lock for the per-memcg cursors makes the writeback fairer and would resolve these corner cases.

Quoted 47 lines · Hao Jia

Quoted 33 lines · Yosry Ahmed

Quoted 21 lines

Quoted 21 lines

Quoted 13 lines

Quoted 5 lines

Quoted 4 lines

Proactive writeback also wants a similar per-memcg cursor that is scoped to the specified memcg, so that repeated invocations against the same memcg make forward progress across its descendant memcgs instead of restarting from the first child memcg each time.

Quoted 7 lines

Is this a problem in practice?

Is the concern the overhead of scanning memcgs repeatedly, or lack of fairness? I wonder if we should just do writeback in batches from all memcgs, similar to how reclaim does it, then evaluate at the end if we need to start over?

Quoted 5 lines

Not using a per-cgroup cursor will cause issues for "repeated small-budget calls" cases. For example, repeatedly triggering a 2MB writeback might result in only writing back pages from the first few child memcgs every time. In the worst-case scenario (where the writeback amount is less than WB_BATCH), it might only ever write back from the first child memcg.

Right, so a fairness concern?

Quoted 7 lines

Quoted 3 lines

I wonder if we should just reclaim a batch from each memcg, then check if we reached the goal, otherwise start over. If the batch size is small enough that should work?

Even with a small batch size, for small writeback requests triggered by user-space (e.g., 2MB, which is batch size * N), it might still repeatedly write back from only the first N child memcgs.

Yes, I understand, I am asking if this is a problem in practice. For this to be a problem we'd need to trigger small writeback requests and have many memcgs.

Quoted 7 lines

Quoted 2 lines

This could cause the user-space agent to prematurely give up on zswap writeback.

Why? The kernel should not return before trying to writeback from all memcgs. If we scan the first N child memcgs and did not writeback enough, we should keep going, right?

Yes, this issue is not caused by the kernel, but rather by our user-space agent itself.

Quoted 8 lines

For instance, suppose a parent memcg has two children, memcg1 and memcg2, each with 200MB of zswap (100MB inactive). Triggering proactive writeback on the parent memcg will exhaust memcg1's inactive zswap pages. After that, even though memcg2 still has plenty of inactive zswap pages, it will continue to write back memcg1's active zswap pages. Writing back active zswap pages causes the user-space agent to prematurely abort the writeback because it detects that certain memcg metrics have exceeded predefined thresholds.

This will only happen if the reclaim size is smaller than the batch size, right? Otherwise the kernel should reclaim more or less equally from both memcgs?

Quoted 5 lines

Of course, real-world scenarios are much more complex, and this kind of case is extremely rare in our environment.

That being said, your suggestion of using the global lock for the per-memcg cursors makes the writeback fairer and would resolve these corner cases.

Right, but I'd rather not do per-memcg cursors at all if we can avoid it. Will using batches help make reclaim fair over all memcgs without a cursor?

We can always add the cursor later if needed.

Quoted 9 lines

Quoted 8 lines

For instance, suppose a parent memcg has two children, memcg1 and memcg2, each with 200MB of zswap (100MB inactive). Triggering proactive writeback on the parent memcg will exhaust memcg1's inactive zswap pages. After that, even though memcg2 still has plenty of inactive zswap pages, it will continue to write back memcg1's active zswap pages. Writing back active zswap pages causes the user-space agent to prematurely abort the writeback because it detects that certain memcg metrics have exceeded predefined thresholds.

Quoted 4 lines

This will only happen if the reclaim size is smaller than the batch size, right? Otherwise the kernel should reclaim more or less equally from both memcgs?

I gave it some thought. Not using a cursor could lead to unfairness issues with certain writeback sizes:

- If the writeback size is an odd multiple of WB_BATCH (e.g.,
triggering a writeback of 3 * WB_BATCH), with 2 child cgroups, the writeback ratio might end up being 2:1.
- If a memcg has 5 child cgroups and a writeback of 2 * WB_BATCH is
triggered, it might repeatedly write back from only the first 2 child cgroups.

Although setting a smaller WB_BATCH might mitigate this unfairness, it could hurt writeback efficiency. Let's just use per-memcg cursors to completely fix these corner cases.

Quoted 24 lines

Quoted 9 lines

Quoted 8 lines

For instance, suppose a parent memcg has two children, memcg1 and memcg2, each with 200MB of zswap (100MB inactive). Triggering proactive writeback on the parent memcg will exhaust memcg1's inactive zswap pages. After that, even though memcg2 still has plenty of inactive zswap pages, it will continue to write back memcg1's active zswap pages. Writing back active zswap pages causes the user-space agent to prematurely abort the writeback because it detects that certain memcg metrics have exceeded predefined thresholds.

Quoted 4 lines

This will only happen if the reclaim size is smaller than the batch size, right? Otherwise the kernel should reclaim more or less equally from both memcgs?

I gave it some thought. Not using a cursor could lead to unfairness issues with certain writeback sizes:

- If the writeback size is an odd multiple of WB_BATCH (e.g.,
triggering a writeback of 3 * WB_BATCH), with 2 child cgroups, the writeback ratio might end up being 2:1.
- If a memcg has 5 child cgroups and a writeback of 2 * WB_BATCH is
triggered, it might repeatedly write back from only the first 2 child cgroups.

Quoted 3 lines

Although setting a smaller WB_BATCH might mitigate this unfairness, it could hurt writeback efficiency. Let's just use per-memcg cursors to completely fix these corner cases.

Exactly, the batch size should be small enough that any unfairness is not a problem. I would honestly just do batching without a per-memcg cursor, unless we have numbers to prove that the efficiency is affected when we use a small batch size. Let's only introduce complexity when needed please.

Quoted 28 lines · Yosry Ahmed

Quoted 24 lines

Quoted 9 lines

Quoted 8 lines

For instance, suppose a parent memcg has two children, memcg1 and memcg2, each with 200MB of zswap (100MB inactive). Triggering proactive writeback on the parent memcg will exhaust memcg1's inactive zswap pages. After that, even though memcg2 still has plenty of inactive zswap pages, it will continue to write back memcg1's active zswap pages. Writing back active zswap pages causes the user-space agent to prematurely abort the writeback because it detects that certain memcg metrics have exceeded predefined thresholds.

Quoted 4 lines

This will only happen if the reclaim size is smaller than the batch size, right? Otherwise the kernel should reclaim more or less equally from both memcgs?

I gave it some thought. Not using a cursor could lead to unfairness issues with certain writeback sizes:

- If the writeback size is an odd multiple of WB_BATCH (e.g.,
triggering a writeback of 3 * WB_BATCH), with 2 child cgroups, the writeback ratio might end up being 2:1.
- If a memcg has 5 child cgroups and a writeback of 2 * WB_BATCH is
triggered, it might repeatedly write back from only the first 2 child cgroups.

Quoted 3 lines

Although setting a smaller WB_BATCH might mitigate this unfairness, it could hurt writeback efficiency. Let's just use per-memcg cursors to completely fix these corner cases.

Quoted 5 lines

Exactly, the batch size should be small enough that any unfairness is not a problem. I would honestly just do batching without a per-memcg cursor, unless we have numbers to prove that the efficiency is affected when we use a small batch size. Let's only introduce complexity when needed please.

If you prefer not to use per-cgroup cursors, do we still need to keep the global cursor (i.e., the root cgroup's cursor) zswap_next_shrink? I found this part to be quite tricky when trying to reuse the main logic of shrink_worker() in zswap_proactive_writeback().

Of course, I think we could also keep zswap_next_shrink and write a small helper to check if it's the root cgroup, allowing us to use different memcg iteration methods.

Quoted 28 lines · Yosry Ahmed

Quoted 27 lines

Quoted 9 lines

Quoted 8 lines

For instance, suppose a parent memcg has two children, memcg1 and memcg2, each with 200MB of zswap (100MB inactive). Triggering proactive writeback on the parent memcg will exhaust memcg1's inactive zswap pages. After that, even though memcg2 still has plenty of inactive zswap pages, it will continue to write back memcg1's active zswap pages. Writing back active zswap pages causes the user-space agent to prematurely abort the writeback because it detects that certain memcg metrics have exceeded predefined thresholds.

Quoted 4 lines

This will only happen if the reclaim size is smaller than the batch size, right? Otherwise the kernel should reclaim more or less equally from both memcgs?

I gave it some thought. Not using a cursor could lead to unfairness issues with certain writeback sizes:

- If the writeback size is an odd multiple of WB_BATCH (e.g.,
triggering a writeback of 3 * WB_BATCH), with 2 child cgroups, the writeback ratio might end up being 2:1.
- If a memcg has 5 child cgroups and a writeback of 2 * WB_BATCH is
triggered, it might repeatedly write back from only the first 2 child cgroups.

Although setting a smaller WB_BATCH might mitigate this unfairness, it could hurt writeback efficiency. Let's just use per-memcg cursors to completely fix these corner cases.

Quoted 5 lines

Exactly, the batch size should be small enough that any unfairness is not a problem. I would honestly just do batching without a per-memcg cursor, unless we have numbers to prove that the efficiency is affected when we use a small batch size. Let's only introduce complexity when needed please.

Quoted 32 lines · Hao Jia

Quoted 28 lines · Yosry Ahmed

Quoted 27 lines

Quoted 9 lines

Quoted 8 lines

For instance, suppose a parent memcg has two children, memcg1 and memcg2, each with 200MB of zswap (100MB inactive). Triggering proactive writeback on the parent memcg will exhaust memcg1's inactive zswap pages. After that, even though memcg2 still has plenty of inactive zswap pages, it will continue to write back memcg1's active zswap pages. Writing back active zswap pages causes the user-space agent to prematurely abort the writeback because it detects that certain memcg metrics have exceeded predefined thresholds.

Quoted 4 lines

This will only happen if the reclaim size is smaller than the batch size, right? Otherwise the kernel should reclaim more or less equally from both memcgs?

I gave it some thought. Not using a cursor could lead to unfairness issues with certain writeback sizes:

- If the writeback size is an odd multiple of WB_BATCH (e.g.,
triggering a writeback of 3 * WB_BATCH), with 2 child cgroups, the writeback ratio might end up being 2:1.
- If a memcg has 5 child cgroups and a writeback of 2 * WB_BATCH is
triggered, it might repeatedly write back from only the first 2 child cgroups.

Although setting a smaller WB_BATCH might mitigate this unfairness, it could hurt writeback efficiency. Let's just use per-memcg cursors to completely fix these corner cases.

Quoted 5 lines

Quoted 5 lines

Exactly, the batch size should be small enough that any unfairness is not a problem. I would honestly just do batching without a per-memcg cursor, unless we have numbers to prove that the efficiency is affected when we use a small batch size. Let's only introduce complexity when needed please.

I'm impartial towards the complexity of per-memcg cursor. I don't think it's that big of a deal, but only if it's warranted.

Hao, if you're convinced that doing small batch is not efficient, could you run some experiments to show the improvement bigger batchign and fairness? Maybe implement a small batch, no-memcg cursor first. Then implement a patch on top of it to add per-memcg cursor, and show how much performance win we can get from that patch on top of the patch series?

Quoted 1 line · Nhat Pham

Thanks for the suggestion!

I ran some tests and found that neither the per-memcg cursor nor different batch sizes have a significant impact on proactive writeback performance. However, exactly as we suspected, without the per-memcg cursor, the writeback distribution among child memcgs is highly unfair.

Test Setup:

zswap config: 18G capacity, LZ4 compression.
cgroup hierarchy: 1 parent test memcg with 10 child memcgs.
Allocation: Allocated 1600MB of anonymous pages in each child memcg.
To ensure compressibility, the first half of each page was filled with random data and the second half with zeros.
Force to zswap: Ran echo "1600M" > memory.reclaim on each child memcg
to squeeze all their memory into zswap.
Trigger writeback: Ran echo "<size> zswap_writeback_only" >
memory.reclaim on the parent cgroup 200 times, with a 2-second interval between each run.
Metric: Monitored the zswpwb_proactive metric in memory.stat to
observe the writeback volume.
**Note**: The size here refers to the uncompressed memory size. Also,
since the second-chance algorithm would cause many writebacks to fall short of the target size, I **bypassed** it during these tests to avoid interference.

Without cursor (size: 1M, batch: 32)

   child        wb_pages        wb_MB     share%
   child0           6368        24.88      12.50
   child1           6368        24.88      12.50
   child2           6368        24.88      12.50
   child3           6368        24.88      12.50
   child4           6368        24.88      12.50
   child5           6368        24.88      12.50
   child6           6368        24.88      12.50
   child7           6368        24.88      12.50
   child8              0         0.00       0.00
   child9              0         0.00       0.00
Without cursor (size: 1M, batch: 128)
   child        wb_pages        wb_MB     share%
   child0          25472        99.50      50.00
   child1          25472        99.50      50.00
   child2              0         0.00       0.00
   child3              0         0.00       0.00
   child4              0         0.00       0.00
   child5              0         0.00       0.00
   child6              0         0.00       0.00
   child7              0         0.00       0.00
   child8              0         0.00       0.00
   child9              0         0.00       0.00
Without cursor (size: 6M, batch: 128)
   child        wb_pages        wb_MB     share%
   child0          51200       200.00      16.67
   child1          51200       200.00      16.67
   child2          25600       100.00       8.33
   child3          25600       100.00       8.33
   child4          25600       100.00       8.33
   child5          25600       100.00       8.33
   child6          25600       100.00       8.33
   child7          25600       100.00       8.33
   child8          25600       100.00       8.33
   child9          25600       100.00       8.33

With cursor (size: 1M, batch: 32)

   child        wb_pages        wb_MB     share%
   child0           5120        20.00      10.00
   child1           5120        20.00      10.00
   child2           5120        20.00      10.00
   child3           5120        20.00      10.00
   child4           5120        20.00      10.00
   child5           5120        20.00      10.00
   child6           5120        20.00      10.00
   child7           5120        20.00      10.00
   child8           5120        20.00      10.00
   child9           5120        20.00      10.00
With cursor (size: 1M, batch: 128)
   child        wb_pages        wb_MB     share%
   child0           5120        20.00      10.00
   child1           5120        20.00      10.00

   child2           5120        20.00      10.00
   child3           5120        20.00      10.00
   child4           5120        20.00      10.00
   child5           5120        20.00      10.00
   child6           5120        20.00      10.00
   child7           5120        20.00      10.00
   child8           5120        20.00      10.00
   child9           5120        20.00      10.00

Quoted 83 lines · Hao Jia

Quoted 1 line · Nhat Pham

Thanks for the suggestion!

I ran some tests and found that neither the per-memcg cursor nor different batch sizes have a significant impact on proactive writeback performance. However, exactly as we suspected, without the per-memcg cursor, the writeback distribution among child memcgs is highly unfair.

Test Setup:

zswap config: 18G capacity, LZ4 compression.
cgroup hierarchy: 1 parent test memcg with 10 child memcgs.
Allocation: Allocated 1600MB of anonymous pages in each child memcg.
To ensure compressibility, the first half of each page was filled with random data and the second half with zeros.
Force to zswap: Ran echo "1600M" > memory.reclaim on each child memcg
to squeeze all their memory into zswap.
Trigger writeback: Ran echo "<size> zswap_writeback_only" >
memory.reclaim on the parent cgroup 200 times, with a 2-second interval between each run.
Metric: Monitored the zswpwb_proactive metric in memory.stat to
observe the writeback volume.
**Note**: The size here refers to the uncompressed memory size. Also,
since the second-chance algorithm would cause many writebacks to fall short of the target size, I **bypassed** it during these tests to avoid interference.

Without cursor (size: 1M, batch: 32)

   child        wb_pages        wb_MB     share%
   child0           6368        24.88      12.50
   child1           6368        24.88      12.50
   child2           6368        24.88      12.50
   child3           6368        24.88      12.50
   child4           6368        24.88      12.50
   child5           6368        24.88      12.50
   child6           6368        24.88      12.50
   child7           6368        24.88      12.50
   child8              0         0.00       0.00
   child9              0         0.00       0.00
Without cursor (size: 1M, batch: 128)
   child        wb_pages        wb_MB     share%
   child0          25472        99.50      50.00
   child1          25472        99.50      50.00
   child2              0         0.00       0.00
   child3              0         0.00       0.00
   child4              0         0.00       0.00
   child5              0         0.00       0.00
   child6              0         0.00       0.00
   child7              0         0.00       0.00
   child8              0         0.00       0.00
   child9              0         0.00       0.00
Without cursor (size: 6M, batch: 128)
   child        wb_pages        wb_MB     share%
   child0          51200       200.00      16.67
   child1          51200       200.00      16.67
   child2          25600       100.00       8.33
   child3          25600       100.00       8.33
   child4          25600       100.00       8.33
   child5          25600       100.00       8.33
   child6          25600       100.00       8.33
   child7          25600       100.00       8.33
   child8          25600       100.00       8.33
   child9          25600       100.00       8.33

With cursor (size: 1M, batch: 32)

   child        wb_pages        wb_MB     share%
   child0           5120        20.00      10.00
   child1           5120        20.00      10.00
   child2           5120        20.00      10.00
   child3           5120        20.00      10.00
   child4           5120        20.00      10.00
   child5           5120        20.00      10.00
   child6           5120        20.00      10.00
   child7           5120        20.00      10.00
   child8           5120        20.00      10.00
   child9           5120        20.00      10.00
With cursor (size: 1M, batch: 128)
   child        wb_pages        wb_MB     share%
   child0           5120        20.00      10.00
   child1           5120        20.00      10.00

Quoted 8 lines

   child2           5120        20.00      10.00
   child3           5120        20.00      10.00
   child4           5120        20.00      10.00
   child5           5120        20.00      10.00
   child6           5120        20.00      10.00
   child7           5120        20.00      10.00
   child8           5120        20.00      10.00
   child9           5120        20.00      10.00

Yeah OTOH, we don't really make fairness an API contract here. When you set up a proactive reclaim scheme, if you decide to target a cgroup (and not its children separately), everything underneath it is fair game to the kernel in any split that we fancy. If you want true fairness or a desired split, you have to treat them as independent memory domains and set up proactive reclaim to hit each child cgroup separately (i.e one "echo > memory.reclaim" for each of them). This is necessary for example if each child represents a separate, isolated service/container/tenant. And maybe this is actually what you really want - hit the ancestor cgroup very lightly for the stuff it owns, but then dedidcate most of the reclaim effort at the leaf cgroups independently?

But OTOH, this does seem like a recipe for inefficient reclaim. We might exhaust hotter memory of a cgroup while sparing colder memory of another cgroup... But maybe if they're all cold anyway, then who cares, and eventually you'll get to the cold stuff of other child?

Yosry, what's the concern here? Is it space overhead, or overall code complexity?

But OTOH, this does seem like a recipe for inefficient reclaim. We might exhaust hotter memory of a cgroup while sparing colder memory of another cgroup... But maybe if they're all cold anyway, then who cares, and eventually you'll get to the cold stuff of other child?

Quoted 5 lines

But OTOH, this does seem like a recipe for inefficient reclaim. We might exhaust hotter memory of a cgroup while sparing colder memory of another cgroup... But maybe if they're all cold anyway, then who cares, and eventually you'll get to the cold stuff of other child?

Forgot to respond to this part, the unfairness is limited to the batch size per-invocation, so it should be fine as long as you don't divide the amount over 100 iterations for some reason. Also yes, all memory in zswap is cold, the relative coldness is not that important (e.g. compared to relative coldness during reclaim).

Quoted 11 lines · Yosry Ahmed

Quoted 5 lines

But OTOH, this does seem like a recipe for inefficient reclaim. We might exhaust hotter memory of a cgroup while sparing colder memory of another cgroup... But maybe if they're all cold anyway, then who cares, and eventually you'll get to the cold stuff of other child?

Forgot to respond to this part, the unfairness is limited to the batch size per-invocation, so it should be fine as long as you don't divide the amount over 100 iterations for some reason. Also yes, all memory in zswap is cold, the relative coldness is not that important (e.g. compared to relative coldness during reclaim).

Ok then yeah, I think we should shelve per-memcg cursor for the next version. Down the line, if we have more data that unfairness is an issue, we can always fix it. One step at a time :)

Quoted 13 lines · Nhat Pham

Quoted 11 lines · Yosry Ahmed

Quoted 5 lines

But OTOH, this does seem like a recipe for inefficient reclaim. We might exhaust hotter memory of a cgroup while sparing colder memory of another cgroup... But maybe if they're all cold anyway, then who cares, and eventually you'll get to the cold stuff of other child?

Forgot to respond to this part, the unfairness is limited to the batch size per-invocation, so it should be fine as long as you don't divide the amount over 100 iterations for some reason. Also yes, all memory in zswap is cold, the relative coldness is not that important (e.g. compared to relative coldness during reclaim).

Quoted 3 lines

Ok then yeah, I think we should shelve per-memcg cursor for the next version. Down the line, if we have more data that unfairness is an issue, we can always fix it. One step at a time :)

Thanks a lot to Yosry, Nhat, and Shakeel for the great suggestions!

Let me summarize what I plan to do in the next version to make sure we are on the same page:

- Drop the per-memcg cursor and keep the root cgroup cursor
(zswap_next_shrink) logic intact.
- Stick to using the zswap_writeback_only key, and change the proactive
writeback size to use the compressed size.
- Consolidate and reuse the logic between shrink_worker() and
shrink_memcg(). Enable batch writeback in the shrink_worker() path, while keeping the writeback behavior in the zswap_store() path unchanged.

Please let me know if I missed or misunderstood anything. Thanks again for clearing things up!

Thanks，
Hao

Quoted 33 lines · Hao Jia

Quoted 13 lines · Nhat Pham

Quoted 11 lines · Yosry Ahmed

Quoted 5 lines

But OTOH, this does seem like a recipe for inefficient reclaim. We might exhaust hotter memory of a cgroup while sparing colder memory of another cgroup... But maybe if they're all cold anyway, then who cares, and eventually you'll get to the cold stuff of other child?

Forgot to respond to this part, the unfairness is limited to the batch size per-invocation, so it should be fine as long as you don't divide the amount over 100 iterations for some reason. Also yes, all memory in zswap is cold, the relative coldness is not that important (e.g. compared to relative coldness during reclaim).

Quoted 3 lines

Ok then yeah, I think we should shelve per-memcg cursor for the next version. Down the line, if we have more data that unfairness is an issue, we can always fix it. One step at a time :)

Thanks a lot to Yosry, Nhat, and Shakeel for the great suggestions!

Let me summarize what I plan to do in the next version to make sure we are on the same page:

- Drop the per-memcg cursor and keep the root cgroup cursor
(zswap_next_shrink) logic intact.
- Stick to using the zswap_writeback_only key, and change the proactive
writeback size to use the compressed size.
- Consolidate and reuse the logic between shrink_worker() and
shrink_memcg(). Enable batch writeback in the shrink_worker() path, while keeping the writeback behavior in the zswap_store() path unchanged.

Quoted 2 lines

Please let me know if I missed or misunderstood anything. Thanks again for clearing things up!

Sorry for the late response, yes I think this makes sense. However, I have some comment about how this interacts with swap tiering, let me reply to the other thread.

Quoted 37 lines · Yosry Ahmed

Quoted 35 lines · Hao Jia

Quoted 13 lines · Nhat Pham

Quoted 11 lines · Yosry Ahmed

Quoted 5 lines

But OTOH, this does seem like a recipe for inefficient reclaim. We might exhaust hotter memory of a cgroup while sparing colder memory of another cgroup... But maybe if they're all cold anyway, then who cares, and eventually you'll get to the cold stuff of other child?

Forgot to respond to this part, the unfairness is limited to the batch size per-invocation, so it should be fine as long as you don't divide the amount over 100 iterations for some reason. Also yes, all memory in zswap is cold, the relative coldness is not that important (e.g. compared to relative coldness during reclaim).

Quoted 3 lines

Ok then yeah, I think we should shelve per-memcg cursor for the next version. Down the line, if we have more data that unfairness is an issue, we can always fix it. One step at a time :)

Thanks a lot to Yosry, Nhat, and Shakeel for the great suggestions!

Let me summarize what I plan to do in the next version to make sure we are on the same page:

- Drop the per-memcg cursor and keep the root cgroup cursor
(zswap_next_shrink) logic intact.
- Stick to using the zswap_writeback_only key, and change the proactive
writeback size to use the compressed size.
- Consolidate and reuse the logic between shrink_worker() and
shrink_memcg(). Enable batch writeback in the shrink_worker() path, while keeping the writeback behavior in the zswap_store() path unchanged.

Please let me know if I missed or misunderstood anything. Thanks again for clearing things up!

Quoted 4 lines

Sorry for the late response, yes I think this makes sense. However, I have some comment about how this interacts with swap tiering, let me reply to the other thread.

I think the swap tiers interaction will be figured out over next cycle. However Hao can/should continue to push and we may decide to let it in orthogonal to swap tiers.

Quoted 44 lines · Shakeel Butt

Quoted 41 lines · Yosry Ahmed

Quoted 33 lines · Hao Jia

Quoted 13 lines · Nhat Pham

Quoted 11 lines · Yosry Ahmed

Quoted 5 lines

But OTOH, this does seem like a recipe for inefficient reclaim. We might exhaust hotter memory of a cgroup while sparing colder memory of another cgroup... But maybe if they're all cold anyway, then who cares, and eventually you'll get to the cold stuff of other child?

Forgot to respond to this part, the unfairness is limited to the batch size per-invocation, so it should be fine as long as you don't divide the amount over 100 iterations for some reason. Also yes, all memory in zswap is cold, the relative coldness is not that important (e.g. compared to relative coldness during reclaim).

Quoted 3 lines

Ok then yeah, I think we should shelve per-memcg cursor for the next version. Down the line, if we have more data that unfairness is an issue, we can always fix it. One step at a time :)

Thanks a lot to Yosry, Nhat, and Shakeel for the great suggestions!

Let me summarize what I plan to do in the next version to make sure we are on the same page:

- Drop the per-memcg cursor and keep the root cgroup cursor
(zswap_next_shrink) logic intact.
- Stick to using the zswap_writeback_only key, and change the proactive
writeback size to use the compressed size.
- Consolidate and reuse the logic between shrink_worker() and
shrink_memcg(). Enable batch writeback in the shrink_worker() path, while keeping the writeback behavior in the zswap_store() path unchanged.

Quoted 2 lines

Please let me know if I missed or misunderstood anything. Thanks again for clearing things up!

Sorry for the late response, yes I think this makes sense. However, I have some comment about how this interacts with swap tiering, let me reply to the other thread.

Quoted 3 lines

I think the swap tiers interaction will be figured out over next cycle. However Hao can/should continue to push and we may decide to let it in orthogonal to swap tiers.

Yeah I think there are a lot of changes we discussed outside of the memcg interface, so maybe keep the interface as-is for now, work on a new version with the other changes, and we can finalize the interface at the end?

From: Hao Jia <[email protected]>

Zswap currently writes back pages to backing swap reactively, triggered either by the shrinker or when the pool reaches its size limit. There is no mechanism to control the amount of writeback for a specific memory cgroup. However, users may want to proactively write back zswap pages, e.g., to free up memory for other applications or to prepare for memory-intensive workloads.

Introduce a "zswap_writeback_only" key to the memory.reclaim cgroup interface. When specified, this key bypasses standard memory reclaim and exclusively performs proactive zswap writeback up to the requested budget. If omitted, the default reclaim behavior remains unchanged.

Example usage:
# Write back 100MB of pages from zswap to the backing swap echo "100M zswap_writeback_only" > memory.reclaim

Quoted 15 lines · Hao Jia

From: Hao Jia <[email protected]>

Zswap currently writes back pages to backing swap reactively, triggered either by the shrinker or when the pool reaches its size limit. There is no mechanism to control the amount of writeback for a specific memory cgroup. However, users may want to proactively write back zswap pages, e.g., to free up memory for other applications or to prepare for memory-intensive workloads.

Introduce a "zswap_writeback_only" key to the memory.reclaim cgroup interface. When specified, this key bypasses standard memory reclaim and exclusively performs proactive zswap writeback up to the requested budget. If omitted, the default reclaim behavior remains unchanged.

Quoted 3 lines

Example usage:
# Write back 100MB of pages from zswap to the backing swap echo "100M zswap_writeback_only" > memory.reclaim

Hmmm, so this 100MB is the pre-compression size? i.e if this 100 MB compresses to 25 MB, then you're only freeing 25 MB?

I'm ok-ish with this, but can you document it?

The rest seems solid to me, FWIW. I'll defer to Johannes and Yosry for opinions on zswap-only proactive reclaim.

Quoted 16 lines · Nhat Pham

Quoted 15 lines · Hao Jia

From: Hao Jia <[email protected]>

Zswap currently writes back pages to backing swap reactively, triggered either by the shrinker or when the pool reaches its size limit. There is no mechanism to control the amount of writeback for a specific memory cgroup. However, users may want to proactively write back zswap pages, e.g., to free up memory for other applications or to prepare for memory-intensive workloads.

Introduce a "zswap_writeback_only" key to the memory.reclaim cgroup interface. When specified, this key bypasses standard memory reclaim and exclusively performs proactive zswap writeback up to the requested budget. If omitted, the default reclaim behavior remains unchanged.

Quoted 8 lines

Quoted 3 lines

Example usage:
# Write back 100MB of pages from zswap to the backing swap echo "100M zswap_writeback_only" > memory.reclaim

Hmmm, so this 100MB is the pre-compression size? i.e if this 100 MB compresses to 25 MB, then you're only freeing 25 MB?

I'm ok-ish with this, but can you document it?

That's a good point. I think pre-compressed size doesn't make sense to be honest. We should care about how much memory we are actually trying to save by doing writeback here.

The pre-compressed size is only useful in determining the blast radius, how many actual pages are going to have slower page faults now. But then, I don't think there's a reasonable way for userspace to decide that.

I understand passing in the compressed size is tricky because we need to keep track of the size of the compressed pages we end up writing back, but it should be doable.

If we really want pre-compressed size here, then yes we need to make it very clear, and I vote that we use a separate interface in this case because memory.reclaim having different meanings for the amount of memory written to it is extremely counter-intuitive.

Quoted 3 lines

The rest seems solid to me, FWIW. I'll defer to Johannes and Yosry for opinions on zswap-only proactive reclaim.

Quoted 30 lines · Yosry Ahmed

Quoted 16 lines · Nhat Pham

Quoted 15 lines · Hao Jia

From: Hao Jia <[email protected]>

Zswap currently writes back pages to backing swap reactively, triggered either by the shrinker or when the pool reaches its size limit. There is no mechanism to control the amount of writeback for a specific memory cgroup. However, users may want to proactively write back zswap pages, e.g., to free up memory for other applications or to prepare for memory-intensive workloads.

Introduce a "zswap_writeback_only" key to the memory.reclaim cgroup interface. When specified, this key bypasses standard memory reclaim and exclusively performs proactive zswap writeback up to the requested budget. If omitted, the default reclaim behavior remains unchanged.

Quoted 8 lines

Quoted 3 lines

Example usage:
# Write back 100MB of pages from zswap to the backing swap echo "100M zswap_writeback_only" > memory.reclaim

Hmmm, so this 100MB is the pre-compression size? i.e if this 100 MB compresses to 25 MB, then you're only freeing 25 MB?

I'm ok-ish with this, but can you document it?

That's a good point. I think pre-compressed size doesn't make sense to be honest. We should care about how much memory we are actually trying to save by doing writeback here.

Quoted 8 lines

The pre-compressed size is only useful in determining the blast radius, how many actual pages are going to have slower page faults now. But then, I don't think there's a reasonable way for userspace to decide that.

I understand passing in the compressed size is tricky because we need to keep track of the size of the compressed pages we end up writing back, but it should be doable.

Agreed. Using pre-compressed size is probably easier to implement. IIRC, interfaces like ZRAM writeback_limit are also calculated using the pre-compressed size.

I'll clarify this in the documentation in the next version.

Quoted 1 line

Quoted 5 lines

If we really want pre-compressed size here, then yes we need to make it very clear, and I vote that we use a separate interface in this case because memory.reclaim having different meanings for the amount of memory written to it is extremely counter-intuitive.

Agree. This would indeed break the semantics of memory.reclaim. I will use a separate interface for proactive writeback in the next version.

Quoted 54 lines · Hao Jia

Quoted 30 lines · Yosry Ahmed

Quoted 16 lines · Nhat Pham

Quoted 15 lines · Hao Jia

From: Hao Jia <[email protected]>

Zswap currently writes back pages to backing swap reactively, triggered either by the shrinker or when the pool reaches its size limit. There is no mechanism to control the amount of writeback for a specific memory cgroup. However, users may want to proactively write back zswap pages, e.g., to free up memory for other applications or to prepare for memory-intensive workloads.

Introduce a "zswap_writeback_only" key to the memory.reclaim cgroup interface. When specified, this key bypasses standard memory reclaim and exclusively performs proactive zswap writeback up to the requested budget. If omitted, the default reclaim behavior remains unchanged.

Quoted 8 lines

Quoted 3 lines

Example usage:
# Write back 100MB of pages from zswap to the backing swap echo "100M zswap_writeback_only" > memory.reclaim

Hmmm, so this 100MB is the pre-compression size? i.e if this 100 MB compresses to 25 MB, then you're only freeing 25 MB?

I'm ok-ish with this, but can you document it?

That's a good point. I think pre-compressed size doesn't make sense to be honest. We should care about how much memory we are actually trying to save by doing writeback here.

Quoted 8 lines

The pre-compressed size is only useful in determining the blast radius, how many actual pages are going to have slower page faults now. But then, I don't think there's a reasonable way for userspace to decide that.

I understand passing in the compressed size is tricky because we need to keep track of the size of the compressed pages we end up writing back, but it should be doable.

Agreed. Using pre-compressed size is probably easier to implement. IIRC, interfaces like ZRAM writeback_limit are also calculated using the pre-compressed size.

I'll clarify this in the documentation in the next version.

Quoted 6 lines

If we really want pre-compressed size here, then yes we need to make it very clear, and I vote that we use a separate interface in this case because memory.reclaim having different meanings for the amount of memory written to it is extremely counter-intuitive.

Quoted 2 lines

Agree. This would indeed break the semantics of memory.reclaim. I will use a separate interface for proactive writeback in the next version.

But doesn't it make more sense to specify the compressed size, which is ultimately the amount of memory you actually want to reclaim.

Quoted 56 lines · Yosry Ahmed

Quoted 54 lines · Hao Jia

Quoted 30 lines · Yosry Ahmed

Quoted 16 lines · Nhat Pham

Quoted 15 lines · Hao Jia

From: Hao Jia <[email protected]>

Zswap currently writes back pages to backing swap reactively, triggered either by the shrinker or when the pool reaches its size limit. There is no mechanism to control the amount of writeback for a specific memory cgroup. However, users may want to proactively write back zswap pages, e.g., to free up memory for other applications or to prepare for memory-intensive workloads.

Introduce a "zswap_writeback_only" key to the memory.reclaim cgroup interface. When specified, this key bypasses standard memory reclaim and exclusively performs proactive zswap writeback up to the requested budget. If omitted, the default reclaim behavior remains unchanged.

Quoted 8 lines

Quoted 3 lines

Example usage:
# Write back 100MB of pages from zswap to the backing swap echo "100M zswap_writeback_only" > memory.reclaim

Hmmm, so this 100MB is the pre-compression size? i.e if this 100 MB compresses to 25 MB, then you're only freeing 25 MB?

I'm ok-ish with this, but can you document it?

That's a good point. I think pre-compressed size doesn't make sense to be honest. We should care about how much memory we are actually trying to save by doing writeback here.

Quoted 8 lines

The pre-compressed size is only useful in determining the blast radius, how many actual pages are going to have slower page faults now. But then, I don't think there's a reasonable way for userspace to decide that.

I understand passing in the compressed size is tricky because we need to keep track of the size of the compressed pages we end up writing back, but it should be doable.

Agreed. Using pre-compressed size is probably easier to implement. IIRC, interfaces like ZRAM writeback_limit are also calculated using the pre-compressed size.

I'll clarify this in the documentation in the next version.

Quoted 6 lines

If we really want pre-compressed size here, then yes we need to make it very clear, and I vote that we use a separate interface in this case because memory.reclaim having different meanings for the amount of memory written to it is extremely counter-intuitive.

Quoted 6 lines

Quoted 2 lines

Agree. This would indeed break the semantics of memory.reclaim. I will use a separate interface for proactive writeback in the next version.

But doesn't it make more sense to specify the compressed size, which is ultimately the amount of memory you actually want to reclaim.

I personally prefer compressed size to pre-compressed size. That's kinda what user cares about, no?

One thing we can do is let users prescribe a compressed size, but internally, we can multiply that by the average compression ratio. That gives us a guesstimate of how many pages we need to reclaim, and you can follow the rest of your implementation as is (perhaps with short-circuit when we reach the goal with fewer pages reclaimed).

Quoted 4 lines

Quoted 3 lines

But doesn't it make more sense to specify the compressed size, which is ultimately the amount of memory you actually want to reclaim.

Quoted 8 lines

I personally prefer compressed size to pre-compressed size. That's kinda what user cares about, no?

One thing we can do is let users prescribe a compressed size, but internally, we can multiply that by the average compression ratio. That gives us a guesstimate of how many pages we need to reclaim, and you can follow the rest of your implementation as is (perhaps with short-circuit when we reach the goal with fewer pages reclaimed).

Got it. I will change it to use the compressed size in the next version.

Yosry, Nhat, should we continue using the zswap_writeback_only key to trigger proactive writeback?

Quoted 15 lines

Quoted 4 lines

Quoted 3 lines

But doesn't it make more sense to specify the compressed size, which is ultimately the amount of memory you actually want to reclaim.

Quoted 8 lines

I personally prefer compressed size to pre-compressed size. That's kinda what user cares about, no?

One thing we can do is let users prescribe a compressed size, but internally, we can multiply that by the average compression ratio. That gives us a guesstimate of how many pages we need to reclaim, and you can follow the rest of your implementation as is (perhaps with short-circuit when we reach the goal with fewer pages reclaimed).

Got it. I will change it to use the compressed size in the next version.

Quoted 2 lines

Yosry, Nhat, should we continue using the zswap_writeback_only key to trigger proactive writeback?

I *really* want the memcg maintainers to chime in here, it's ultimately their call.

Michal? Johannes? Shakeel? Roman? Anyone? :D

Quoted 15 lines

Quoted 4 lines

Quoted 3 lines

But doesn't it make more sense to specify the compressed size, which is ultimately the amount of memory you actually want to reclaim.

Quoted 8 lines

I personally prefer compressed size to pre-compressed size. That's kinda what user cares about, no?

One thing we can do is let users prescribe a compressed size, but internally, we can multiply that by the average compression ratio. That gives us a guesstimate of how many pages we need to reclaim, and you can follow the rest of your implementation as is (perhaps with short-circuit when we reach the goal with fewer pages reclaimed).

Got it. I will change it to use the compressed size in the next version.

Quoted 2 lines

Yosry, Nhat, should we continue using the zswap_writeback_only key to trigger proactive writeback?

I *really* want the memcg maintainers to chime in here, it's ultimately their call.

Michal? Johannes? Shakeel? Roman? Anyone? :D

Quoted 15 lines · Yosry Ahmed

Quoted 15 lines

Quoted 4 lines

Quoted 3 lines

But doesn't it make more sense to specify the compressed size, which is ultimately the amount of memory you actually want to reclaim.

Quoted 8 lines

I personally prefer compressed size to pre-compressed size. That's kinda what user cares about, no?

One thing we can do is let users prescribe a compressed size, but internally, we can multiply that by the average compression ratio. That gives us a guesstimate of how many pages we need to reclaim, and you can follow the rest of your implementation as is (perhaps with short-circuit when we reach the goal with fewer pages reclaimed).

Got it. I will change it to use the compressed size in the next version.

Quoted 7 lines

Quoted 2 lines

Yosry, Nhat, should we continue using the zswap_writeback_only key to trigger proactive writeback?

I *really* want the memcg maintainers to chime in here, it's ultimately their call.

Michal? Johannes? Shakeel? Roman? Anyone? :D

Between the options of having an explicit interface (i.e. memory.zswap.writeback*) or a key (i.e. zswap_writeback_only) to memory.reclaim interface, I prefer the key option. I have not looked into how much proactively reclaiming zswap memory or proactively triggering zswap writeback makes sense but from the perspective of memcg interface, I think the key option would give a more clean solution if we decide in the future that this whole thing was a bad idea.

Next regarding future proofing zswap writeback trigger, do we expect any potential additions/changes/new-features for this interface? For example do we expect in future we may want to trigger the zswap writeback only from a specific node or lowest memory tier?

+Youngjun

Quoted 36 lines · Shakeel Butt

Quoted 15 lines · Yosry Ahmed

Quoted 15 lines

Quoted 4 lines

Quoted 3 lines

But doesn't it make more sense to specify the compressed size, which is ultimately the amount of memory you actually want to reclaim.

Quoted 8 lines

I personally prefer compressed size to pre-compressed size. That's kinda what user cares about, no?

One thing we can do is let users prescribe a compressed size, but internally, we can multiply that by the average compression ratio. That gives us a guesstimate of how many pages we need to reclaim, and you can follow the rest of your implementation as is (perhaps with short-circuit when we reach the goal with fewer pages reclaimed).

Got it. I will change it to use the compressed size in the next version.

Quoted 7 lines

Quoted 2 lines

Yosry, Nhat, should we continue using the zswap_writeback_only key to trigger proactive writeback?

I *really* want the memcg maintainers to chime in here, it's ultimately their call.

Michal? Johannes? Shakeel? Roman? Anyone? :D

Between the options of having an explicit interface (i.e. memory.zswap.writeback*) or a key (i.e. zswap_writeback_only) to memory.reclaim interface, I prefer the key option. I have not looked into how much proactively reclaiming zswap memory or proactively triggering zswap writeback makes sense but from the perspective of memcg interface, I think the key option would give a more clean solution if we decide in the future that this whole thing was a bad idea.

Next regarding future proofing zswap writeback trigger, do we expect any potential additions/changes/new-features for this interface? For example do we expect in future we may want to trigger the zswap writeback only from a specific node or lowest memory tier?

Youngjun is working on swap tiers. At the moment he is more interested in allowing a specific swap device to a memcg or not. I can imagine in future there will be use-cases where there will be a need to demote data on higher tier swap to lower tier swap. What would be the appropriate interface?

BTW does zswap folks think of zswap as a top swap tier or something different?

Quoted 40 lines · Shakeel Butt

+Youngjun

Quoted 36 lines · Shakeel Butt

Quoted 15 lines · Yosry Ahmed

Quoted 15 lines

Quoted 4 lines

Quoted 3 lines

But doesn't it make more sense to specify the compressed size, which is ultimately the amount of memory you actually want to reclaim.

Quoted 8 lines

I personally prefer compressed size to pre-compressed size. That's kinda what user cares about, no?

One thing we can do is let users prescribe a compressed size, but internally, we can multiply that by the average compression ratio. That gives us a guesstimate of how many pages we need to reclaim, and you can follow the rest of your implementation as is (perhaps with short-circuit when we reach the goal with fewer pages reclaimed).

Got it. I will change it to use the compressed size in the next version.

Quoted 7 lines

Quoted 2 lines

Yosry, Nhat, should we continue using the zswap_writeback_only key to trigger proactive writeback?

I *really* want the memcg maintainers to chime in here, it's ultimately their call.

Michal? Johannes? Shakeel? Roman? Anyone? :D

Between the options of having an explicit interface (i.e. memory.zswap.writeback*) or a key (i.e. zswap_writeback_only) to memory.reclaim interface, I prefer the key option. I have not looked into how much proactively reclaiming zswap memory or proactively triggering zswap writeback makes sense but from the perspective of memcg interface, I think the key option would give a more clean solution if we decide in the future that this whole thing was a bad idea.

Next regarding future proofing zswap writeback trigger, do we expect any potential additions/changes/new-features for this interface? For example do we expect in future we may want to trigger the zswap writeback only from a specific node or lowest memory tier?

The way I see it, zswap writeback is just a "special" type of proactive reclaim, but the goal is still proactively freeing cold memory. In that regard, I think it makes sense to have things like node-specific reclaim. Not sure about other extensions, but Hao initially suggested making this age-based, so I think the answer is yes.

For both of these examples (node-specific reclaim, age-based reclaim), I think the same semantics could apply to memory.reclaim in general, which is why I suggested making it a part of memory.reclaim. I also like the idea of having a single proactive reclaim interface in general, but maybe we don't want to overload it too much.

Quoted 7 lines

Youngjun is working on swap tiers. At the moment he is more interested in allowing a specific swap device to a memcg or not. I can imagine in future there will be use-cases where there will be a need to demote data on higher tier swap to lower tier swap. What would be the appropriate interface?

BTW does zswap folks think of zswap as a top swap tier or something different?

I haven't been following the swap tiers work closely, but personally I do think of zswap as a top swap tier.

Things will probably get more
blurry with memory tiers and compressed memory nodes though.

Quoted 9 lines

Quoted 6 lines

Youngjun is working on swap tiers. At the moment he is more interested in allowing a specific swap device to a memcg or not. I can imagine in future there will be use-cases where there will be a need to demote data on higher tier swap to lower tier swap. What would be the appropriate interface?

BTW does zswap folks think of zswap as a top swap tier or something different?

I haven't been following the swap tiers work closely, but personally I do think of zswap as a top swap tier.

Same for me though I imagine swap tiers would introduce some duplication i.e. different way (interface) to set limits for swap tiers for a given memcg.

Quoted 2 lines

Things will probably get more
blurry with memory tiers and compressed memory nodes though.

I think there will still be distinction between byte addressable and fault on access devices.

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Youngjun is working on swap tiers. At the moment he is more interested in allowing a specific swap device to a memcg or not. I can imagine in future there will be use-cases where there will be a need to demote data on higher tier swap to lower tier swap. What would be the appropriate interface?

Quoted 5 lines

Quoted 2 lines

Things will probably get more
blurry with memory tiers and compressed memory nodes though.

I think there will still be distinction between byte addressable and fault on access devices.

Yeah, I think it makes sense to define "swap" as fault on access (zswap, SSD, etc), and memory tiers as byte-addressable (even if you put an SSD behind CXL and make it byte-addressable). But I also remember seeing discussions about unifying memory tiers and swap in a way, and it makes sense from a reclaim perspective (swap or demote first?).

Quoted 7 lines

Quoted 7 lines

Quoted 4 lines

will be use-cases where there will be a need to demote data on higher tier swap to lower tier swap. What would be the appropriate interface?

BTW does zswap folks think of zswap as a top swap tier or something different?

I haven't been following the swap tiers work closely, but personally I do think of zswap as a top swap tier.

Quoted 3 lines

Same for me though I imagine swap tiers would introduce some duplication i.e. different way (interface) to set limits for swap tiers for a given memcg.

On Mon, Jun 08, 2026 at 03:27:07PM -0700, Yosry Ahmed wrote:

+Chris +Kairui +Baoquan

Hello

Thanks for inviting me to the discussion, Shakeel.

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Youngjun is working on swap tiers. At the moment he is more interested in allowing a specific swap device to a memcg or not. I can imagine in future there will be use-cases where there will be a need to demote data on higher tier swap to lower tier swap. What would be the appropriate interface?

Speaking of my work on swap tiers, I recently submitted a patch and am currently considering memcg integration:
https://lore.kernel.org/linux-mm/[email protected]/

The future use-cases imagined above seem to align with this direction. (BTW, I am currently waiting for reviews/feedback from the memcg folks on this patch. Any reviews would be highly appreciated!)

We could potentially assign a target tier
for writeback within the existing memory.zswap.writeback interface.

For instance, '0' could mean disabled, while non-zero values could represent specific tiers, which would maintain backward compatibility with the current version. Alternatively, if zswap is treated as the default top tier, the memory.swap.tiers interface could potentially replace memory.zswap.writeback.

Furthermore, this could be expanded so that each swap tier can demote data user-triggered demotion between swap tiers.

Based on the current patch's ideas combined with my swap tiers concept:

Assuming a hierarchy like:
zswap -> tier1 (SSD swap) -> tier2 (HDD swap) -> tier3 (Network swap)

We could configure the active tiers via a setting like memory.swap.tiers (tier2 enabled, tier3 enabled).

For example, the concept of echo "100M zswap_writeback_only > memory.reclaim" could be extended. A user could run echo "100M tier2 > memory.reclaim" to explicitly trigger demotion from tier2 to tier3.
(BTW, if we combine these features, my personal preference for the keyword format would be <size> <demote_prefix><tier_name>. I think it would be better to explicitly indicate that it is a swap demotion by using a specific prefix followed by the tier name.
Or make demote prefix another key is also possible)

Quoted 40 lines · YoungJun Park

On Mon, Jun 08, 2026 at 03:27:07PM -0700, Yosry Ahmed wrote:

+Chris +Kairui +Baoquan

Hello

Thanks for inviting me to the discussion, Shakeel.

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Youngjun is working on swap tiers. At the moment he is more interested in allowing a specific swap device to a memcg or not. I can imagine in future there will be use-cases where there will be a need to demote data on higher tier swap to lower tier swap. What would be the appropriate interface?

Speaking of my work on swap tiers, I recently submitted a patch and am currently considering memcg integration:
https://lore.kernel.org/linux-mm/[email protected]/

The future use-cases imagined above seem to align with this direction. (BTW, I am currently waiting for reviews/feedback from the memcg folks on this patch. Any reviews would be highly appreciated!)

We could potentially assign a target tier
for writeback within the existing memory.zswap.writeback interface.

For instance, '0' could mean disabled, while non-zero values could represent specific tiers, which would maintain backward compatibility with the current version. Alternatively, if zswap is treated as the default top tier, the memory.swap.tiers interface could potentially replace memory.zswap.writeback.

Furthermore, this could be expanded so that each swap tier can demote data user-triggered demotion between swap tiers.

Based on the current patch's ideas combined with my swap tiers concept:

Assuming a hierarchy like:
zswap -> tier1 (SSD swap) -> tier2 (HDD swap) -> tier3 (Network swap)

We could configure the active tiers via a setting like memory.swap.tiers (tier2 enabled, tier3 enabled).

Quoted 8 lines

For example, the concept of echo "100M zswap_writeback_only > memory.reclaim" could be extended. A user could run echo "100M tier2 > memory.reclaim" to explicitly trigger demotion from tier2 to tier3.
(BTW, if we combine these features, my personal preference for the keyword format would be <size> <demote_prefix><tier_name>. I think it would be better to explicitly indicate that it is a swap demotion by using a specific prefix followed by the tier name.
Or make demote prefix another key is also possible)

I am not sure if proactive demotion between swap tiers would be driven by memory.reclaim, I am guessing a new interface might be more suitable. But yes, you are right that it's very possible that 'zswap_writeback_only' with memory.reclaim will become obsolete once swap tiering matures and starts supporting things like proactive demotion.

Part of me wants to wait until the swap tiering interfaces are figured out so that we don't end up with redundant interfaces, but I also don't want to hold Hao's work since it doesn't directly depend on swap tiering.

Shakeel, how do you want to handle this? I think there's a few options:

1. Add zswap_writeback_only now, and when we have swap tiering demotion it becomes a redundant interface, like memory.zswap.writeback -- or maybe we try to deprecate both of them at that point. It's difficult to remove interfaces tho, but maybe easier to stop supporting zswap_writeback_only.

2. Add zswap_writeback_only behind an experimental config option, to unblock development but have a line of sight to dropping support once we have a swap tiering interface.

3. Wait until we figure out the swap tiering interfaces and then add the proactive zswap writeback as part of it.

WDYT?

Quoted 57 lines · Yosry Ahmed

Quoted 40 lines · YoungJun Park

On Mon, Jun 08, 2026 at 03:27:07PM -0700, Yosry Ahmed wrote:

+Chris +Kairui +Baoquan

Hello

Thanks for inviting me to the discussion, Shakeel.

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Youngjun is working on swap tiers. At the moment he is more interested in allowing a specific swap device to a memcg or not. I can imagine in future there will be use-cases where there will be a need to demote data on higher tier swap to lower tier swap. What would be the appropriate interface?

Speaking of my work on swap tiers, I recently submitted a patch and am currently considering memcg integration:
https://lore.kernel.org/linux-mm/[email protected]/

The future use-cases imagined above seem to align with this direction. (BTW, I am currently waiting for reviews/feedback from the memcg folks on this patch. Any reviews would be highly appreciated!)

We could potentially assign a target tier
for writeback within the existing memory.zswap.writeback interface.

For instance, '0' could mean disabled, while non-zero values could represent specific tiers, which would maintain backward compatibility with the current version. Alternatively, if zswap is treated as the default top tier, the memory.swap.tiers interface could potentially replace memory.zswap.writeback.

Furthermore, this could be expanded so that each swap tier can demote data user-triggered demotion between swap tiers.

Based on the current patch's ideas combined with my swap tiers concept:

Assuming a hierarchy like:
zswap -> tier1 (SSD swap) -> tier2 (HDD swap) -> tier3 (Network swap)

We could configure the active tiers via a setting like memory.swap.tiers (tier2 enabled, tier3 enabled).

Quoted 8 lines

For example, the concept of echo "100M zswap_writeback_only > memory.reclaim" could be extended. A user could run echo "100M tier2 > memory.reclaim" to explicitly trigger demotion from tier2 to tier3.
(BTW, if we combine these features, my personal preference for the keyword format would be <size> <demote_prefix><tier_name>. I think it would be better to explicitly indicate that it is a swap demotion by using a specific prefix followed by the tier name.
Or make demote prefix another key is also possible)

I am not sure if proactive demotion between swap tiers would be driven by memory.reclaim, I am guessing a new interface might be more suitable. But yes, you are right that it's very possible that 'zswap_writeback_only' with memory.reclaim will become obsolete once swap tiering matures and starts supporting things like proactive demotion.

Quoted 4 lines

Part of me wants to wait until the swap tiering interfaces are figured out so that we don't end up with redundant interfaces, but I also don't want to hold Hao's work since it doesn't directly depend on swap tiering.

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.

Quoted 8 lines

Shakeel, how do you want to handle this? I think there's a few options:

1. Add zswap_writeback_only now, and when we have swap tiering demotion it becomes a redundant interface, like memory.zswap.writeback -- or maybe we try to deprecate both of them at that point. It's difficult to remove interfaces tho, but maybe easier to stop supporting zswap_writeback_only.

Quoted 8 lines

2. Add zswap_writeback_only behind an experimental config option, to unblock development but have a line of sight to dropping support once we have a swap tiering interface.

3. Wait until we figure out the swap tiering interfaces and then add the proactive zswap writeback as part of it.

WDYT?

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.

Quoted 83 lines · Shakeel Butt

Quoted 57 lines · Yosry Ahmed

Quoted 40 lines · YoungJun Park

On Mon, Jun 08, 2026 at 03:27:07PM -0700, Yosry Ahmed wrote:

+Chris +Kairui +Baoquan

Hello

Thanks for inviting me to the discussion, Shakeel.

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Youngjun is working on swap tiers. At the moment he is more interested in allowing a specific swap device to a memcg or not. I can imagine in future there will be use-cases where there will be a need to demote data on higher tier swap to lower tier swap. What would be the appropriate interface?

Speaking of my work on swap tiers, I recently submitted a patch and am currently considering memcg integration:
https://lore.kernel.org/linux-mm/[email protected]/

The future use-cases imagined above seem to align with this direction. (BTW, I am currently waiting for reviews/feedback from the memcg folks on this patch. Any reviews would be highly appreciated!)

We could potentially assign a target tier
for writeback within the existing memory.zswap.writeback interface.

For instance, '0' could mean disabled, while non-zero values could represent specific tiers, which would maintain backward compatibility with the current version. Alternatively, if zswap is treated as the default top tier, the memory.swap.tiers interface could potentially replace memory.zswap.writeback.

Furthermore, this could be expanded so that each swap tier can demote data user-triggered demotion between swap tiers.

Based on the current patch's ideas combined with my swap tiers concept:

Assuming a hierarchy like:
zswap -> tier1 (SSD swap) -> tier2 (HDD swap) -> tier3 (Network swap)

We could configure the active tiers via a setting like memory.swap.tiers (tier2 enabled, tier3 enabled).

Quoted 8 lines

For example, the concept of echo "100M zswap_writeback_only > memory.reclaim" could be extended. A user could run echo "100M tier2 > memory.reclaim" to explicitly trigger demotion from tier2 to tier3.
(BTW, if we combine these features, my personal preference for the keyword format would be <size> <demote_prefix><tier_name>. I think it would be better to explicitly indicate that it is a swap demotion by using a specific prefix followed by the tier name.
Or make demote prefix another key is also possible)

I am not sure if proactive demotion between swap tiers would be driven by memory.reclaim, I am guessing a new interface might be more suitable. But yes, you are right that it's very possible that 'zswap_writeback_only' with memory.reclaim will become obsolete once swap tiering matures and starts supporting things like proactive demotion.

Quoted 4 lines

Part of me wants to wait until the swap tiering interfaces are figured out so that we don't end up with redundant interfaces, but I also don't want to hold Hao's work since it doesn't directly depend on swap tiering.

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.

Quoted 8 lines

Shakeel, how do you want to handle this? I think there's a few options:

1. Add zswap_writeback_only now, and when we have swap tiering demotion it becomes a redundant interface, like memory.zswap.writeback -- or maybe we try to deprecate both of them at that point. It's difficult to remove interfaces tho, but maybe easier to stop supporting zswap_writeback_only.

Quoted 8 lines

2. Add zswap_writeback_only behind an experimental config option, to unblock development but have a line of sight to dropping support once we have a swap tiering interface.

3. Wait until we figure out the swap tiering interfaces and then add the proactive zswap writeback as part of it.

WDYT?

Quoted 7 lines

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.

To summarize the discussions so far, the following points align well.

- Per-cgroup swap control, as I suggested.
- Proactive zswap writeback (Hao's usecase)
- Swap device target demotion(if it wants selective, then it is more better), as you mentioned:
https://lore.kernel.org/linux-mm/[email protected]/
- Virtual Swap on/off in the future, as Nhat mentioned:
https://lore.kernel.org/linux-mm/[email protected]/
- The memory.zswap.writeback alternative (no hierarchy model conflict)
- zswap is first swap tier.
- Promotion. (Also better for selectve usage)
- tier based swap policy (e.g round-robin...)

To accelerate this work, I believe we should reach a consensus and merge the currently proposed swap_tier interface :)

If the above approach is difficult, I would like to suggest an alternative for progress with the memcg interfaces removed:

1) We could make zswap the first tier and create
a use case where memory.zswap.writeback internally is handled by tier logic.

2) Or simply merge the swap_tier infrastructure itself first.

This would allow the swap_tier infrastructure to be merged and discussed more easily.

If it takes longer to adopt swap_tier anyway, by doing so we progress next step as a experimental feature.

- Apply per-cgroup swap as an experimental (debugfs) feature.
- Apply Hao's use case experimentally or as it is as Yosry suggested. (future migration to swap tier)

How do you think?

(FYI: My emails to kernel.org are failing due to internal server issues.)

Thank you
Youngjun Park

Quoted 10 lines

Quoted 7 lines

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!

Quoted 8 lines

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.

Quoted 4 lines

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.

Quoted 41 lines

To summarize the discussions so far, the following points align well.

- Per-cgroup swap control, as I suggested.
- Proactive zswap writeback (Hao's usecase)
- Swap device target demotion(if it wants selective, then it is more better), as you mentioned:
https://lore.kernel.org/linux-mm/[email protected]/
- Virtual Swap on/off in the future, as Nhat mentioned:
https://lore.kernel.org/linux-mm/[email protected]/
- The memory.zswap.writeback alternative (no hierarchy model conflict)
- zswap is first swap tier.
- Promotion. (Also better for selectve usage)
- tier based swap policy (e.g round-robin...)

To accelerate this work, I believe we should reach a consensus and merge the currently proposed swap_tier interface :)

If the above approach is difficult, I would like to suggest an alternative for progress with the memcg interfaces removed:

1) We could make zswap the first tier and create
a use case where memory.zswap.writeback internally is handled by tier logic.

2) Or simply merge the swap_tier infrastructure itself first.

This would allow the swap_tier infrastructure to be merged and discussed more easily.

If it takes longer to adopt swap_tier anyway, by doing so we progress next step as a experimental feature.

- Apply per-cgroup swap as an experimental (debugfs) feature.
- Apply Hao's use case experimentally or as it is as Yosry suggested. (future migration to swap tier)

How do you think?

(FYI: My emails to kernel.org are failing due to internal server issues.)

Thank you
Youngjun Park

In that case, the internal logic could stay roughly the same rather than counting via a page counter. Something like:

1. Change the interface shell: tier.*.max — allow only 0 ~ max.

2. Keep the internal logic as is: 0 disables the mask (child memcgs off too), max enables it (child memcgs on too).

3. memory.zswap.max integrates naturally (it's memory."tier_name".max).

Let me clarify a part I wrote confusingly. Handling memory.zswap.writeback via tiers is possible, but I don't think the interface itself would be replaced even if memory.swap.tiers is adopted.

Selecting only zswap in memory.swap.tiers would not just disable writeback.it would also block regular swap entirely, which differs slightly from the current semantic. (... "Per the cgroup v2 docs: a zswap-only tier setting is subtly different from setting memory.swap.max to 0, since it still allows pages to be written to the zswap pool; this has no effect if zswap is disabled, and swapping is allowed unless memory.swap.max is set to 0.")

So the interface itself needs to be retained, and it could be extended toward selective writeback — e.g., passing a desired tier into memory.zswap.writeback so writeback targets only that tier. Currently it only controls on/off. Other tiers probably don't need this. demotion based on the selected tier should be enough.

Thanks,
Youngjun Park

....

Quoted 10 lines

Quoted 4 lines

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.

Good idea, and it's certainly feasible. When I considered this a while ago, the reasons I didn't take this direction were:

1. There's no real-world usage for adjusting the swap tier amount (it's either 0 or MAX). That said, your suggestion to initially allow only 0 and max is the killing point, and it's making me reconsider.

2. The implementation cost seems high. The current implementation handles this at runtime via simple masking.

3. Relationship with swap.max:
- If we tie it to the current interface, wouldn't limiting the swap amount within a selected tier already be possible? I wonder if that alone is enough.
- If we add tier.max, it would need to be a subset of swap.max. (Any other complexities here?)

4. vswap enable/disable: vswap doesn't seem to have an amount-control aspect, so an on/off semantic would be clearer.
https://lore.kernel.org/linux-mm/ai5kOOmR1LPTWs1J@yjaykim-PowerEdge-T330/T/#m8831ec057bf9387978d3bd698f51920600e09a04

In that case, the internal logic could stay roughly the same rather than counting via a page counter. Something like:

1. Change the interface shell: tier.*.max — allow only 0 ~ max.
2. Keep the internal logic as is: 0 disables the mask (child memcgs off too), max enables it (child memcgs on too).
3. memory.zswap.max integrates naturally (it's memory."tier_name".max).
4. Extend later if use cases arise.

On balance I still lean toward the current interface, but if a per-tier max is the better fit for memcg's direction and others feel the same, I'm happy to switch. I'd like to hear Shakeel's thoughts again, and I'm curious about others' opinions too.

A few more perspectives on the points below.

Quoted 43 lines

I will respond to your other points later when I have time.

Quoted 41 lines

To summarize the discussions so far, the following points align well.

- Per-cgroup swap control, as I suggested.
- Proactive zswap writeback (Hao's usecase)
- Swap device target demotion(if it wants selective, then it is more better), as you mentioned:
https://lore.kernel.org/linux-mm/[email protected]/
- Virtual Swap on/off in the future, as Nhat mentioned:
https://lore.kernel.org/linux-mm/[email protected]/
- The memory.zswap.writeback alternative (no hierarchy model conflict)
- zswap is first swap tier.
- Promotion. (Also better for selectve usage)
- tier based swap policy (e.g round-robin...)

To accelerate this work, I believe we should reach a consensus and merge the currently proposed swap_tier interface :)

If the above approach is difficult, I would like to suggest an alternative for progress with the memcg interfaces removed:

1) We could make zswap the first tier and create
a use case where memory.zswap.writeback internally is handled by tier logic.

2) Or simply merge the swap_tier infrastructure itself first.

This would allow the swap_tier infrastructure to be merged and discussed more easily.

If it takes longer to adopt swap_tier anyway, by doing so we progress next step as a experimental feature.

- Apply per-cgroup swap as an experimental (debugfs) feature.
- Apply Hao's use case experimentally or as it is as Yosry suggested. (future migration to swap tier)

How do you think?

(FYI: My emails to kernel.org are failing due to internal server issues.)

Thank you
Youngjun Park

Let me clarify a part I wrote confusingly. Handling memory.zswap.writeback via tiers is possible, but I don't think the interface itself would be replaced even if memory.swap.tiers is adopted.

Selecting only zswap in memory.swap.tiers would not just disable writeback.it would also block regular swap entirely, which differs slightly from the current semantic. (... "Per the cgroup v2 docs: a zswap-only tier setting is subtly different from setting memory.swap.max to 0, since it still allows pages to be written to the zswap pool; this has no effect if zswap is disabled, and swapping is allowed unless memory.swap.max is set to 0.")

So the interface itself needs to be retained, and it could be extended toward selective writeback — e.g., passing a desired tier into memory.zswap.writeback so writeback targets only that tier. Currently it only controls on/off. Other tiers probably don't need this. demotion based on the selected tier should be enough.

Thanks,
Youngjun Park

Quoted 4 lines

In that case, the internal logic could stay roughly the same rather than counting via a page counter. Something like:

1. Change the interface shell: tier.*.max — allow only 0 ~ max.

What about a single interface as I suggested to remain consistent with memory tiering?

Quoted 2 lines

2. Keep the internal logic as is: 0 disables the mask (child memcgs off too), max enables it (child memcgs on too).

I think a child should be able to disable a swap tier enabled by the parent, but not vice versa.

Quoted 1 line

3. memory.zswap.max integrates naturally (it's memory."tier_name".max).

Not really. memory.zswap.max is in terms of memory usage (compressed size), not swap usage (uncompressed size).

[..]

Quoted 11 lines

Let me clarify a part I wrote confusingly. Handling memory.zswap.writeback via tiers is possible, but I don't think the interface itself would be replaced even if memory.swap.tiers is adopted.

Selecting only zswap in memory.swap.tiers would not just disable writeback.it would also block regular swap entirely, which differs slightly from the current semantic. (... "Per the cgroup v2 docs: a zswap-only tier setting is subtly different from setting memory.swap.max to 0, since it still allows pages to be written to the zswap pool; this has no effect if zswap is disabled, and swapping is allowed unless memory.swap.max is set to 0.")

I don't understand. How is disabling zswap writeback not equivalent to only enabling zswap as a tier?

Do you just mean the fact that disabling zswap writeback is a noop of zswap is disabled? It's a different interface so I think a small

semantic difference is okay. In practice, I doubt that zswap is being disabled at runtime.

- "zswap tier only": Only zswap is allowed. Fallback to other swap is blocked.
- "zswap writeback disabled": zswap is allowed, but if zswap_store() fails, pages can still fall back to other swap devices.

...

Quoted 4 lines

- "zswap tier only": Only zswap is allowed. Fallback to other swap is blocked.
- "zswap writeback disabled": zswap is allowed, but if zswap_store() fails, pages can still fall back to other swap devices.

Upon double-checking the code, my previous clarification was wrong. You are right. Sorry for the confusion. "zswap tier only" is indeed equivalent to "zswap writeback disabled".
(I'm not sure why I read the code that way...)

As I initially thought, it might be possible to replace the zswap writeback control with the tiering mechanism.

If we need to keep the existing interface, we can integrate or share the underlying logic (though the specific details need more thought anyway).

It can be summarized as follows:

- "zswap tier only" + "zswap writeback disable" -> meaningless (noop)
- "zswap tier only" + "zswap writeback enable" -> meaningless (no writabck backend exist)
- "zswap tier with other tiers" + "zswap writeback disable" -> uses only zswap (can be replaced by "zswap tier only". This code could be intergrated, modified or something.)
- "zswap tier with other tiers" + "zswap writeback enable" -> works as is

As mentioned in the previous email, the zswap tier on/off control comes as a bonus (though, as you pointed out, we may need to discuss if it's actually needed).

BR,
Youngjun

Quoted 18 lines · YoungJun Park

...

Quoted 4 lines

- "zswap tier only": Only zswap is allowed. Fallback to other swap is blocked.
- "zswap writeback disabled": zswap is allowed, but if zswap_store() fails, pages can still fall back to other swap devices.

Upon double-checking the code, my previous clarification was wrong. You are right. Sorry for the confusion. "zswap tier only" is indeed equivalent to "zswap writeback disabled".
(I'm not sure why I read the code that way...)

As I initially thought, it might be possible to replace the zswap writeback control with the tiering mechanism.

If we need to keep the existing interface, we can integrate or share the underlying logic (though the specific details need more thought anyway).

Quoted 7 lines

It can be summarized as follows:

- "zswap tier only" + "zswap writeback disable" -> meaningless (noop)
- "zswap tier only" + "zswap writeback enable" -> meaningless (no writabck backend exist)
- "zswap tier with other tiers" + "zswap writeback disable" -> uses only zswap (can be replaced by "zswap tier only". This code could be intergrated, modified or something.)
- "zswap tier with other tiers" + "zswap writeback enable" -> works as is

Hmm we might want to somehow disable memory.zswap.writeback if tiering is enabled, to avoid having to deal with this. But I am not sure how possible this is.

Quoted 20 lines · Yosry Ahmed

Quoted 18 lines · YoungJun Park

...

Quoted 4 lines

- "zswap tier only": Only zswap is allowed. Fallback to other swap is blocked.
- "zswap writeback disabled": zswap is allowed, but if zswap_store() fails, pages can still fall back to other swap devices.

Upon double-checking the code, my previous clarification was wrong. You are right. Sorry for the confusion. "zswap tier only" is indeed equivalent to "zswap writeback disabled".
(I'm not sure why I read the code that way...)

As I initially thought, it might be possible to replace the zswap writeback control with the tiering mechanism.

If we need to keep the existing interface, we can integrate or share the underlying logic (though the specific details need more thought anyway).

Quoted 7 lines

Quoted 7 lines

It can be summarized as follows:

- "zswap tier only" + "zswap writeback disable" -> meaningless (noop)
- "zswap tier only" + "zswap writeback enable" -> meaningless (no writabck backend exist)
- "zswap tier with other tiers" + "zswap writeback disable" -> uses only zswap (can be replaced by "zswap tier only". This code could be intergrated, modified or something.)
- "zswap tier with other tiers" + "zswap writeback enable" -> works as is

TBH, without vswap, we should not allow setting zswap as its own tier. It's meaningless. Maybe makes it a no-op, and warn users what they're setting is gibberish?

Quoted 4 lines · Nhat Pham

TBH, without vswap, we should not allow setting zswap as its own tier. It's meaningless. Maybe makes it a no-op, and warn users what they're setting is gibberish?

Why? vswap is transparent to the user. Why can't zswap be its own tier?

Quoted 3 lines · Yosry Ahmed

Quoted 1 line · Nhat Pham

Quoted 5 lines

Quoted 3 lines

TBH, without vswap, we should not allow setting zswap as its own tier. It's meaningless. Maybe makes it a no-op, and warn users what they're setting is gibberish?

Why? vswap is transparent to the user. Why can't zswap be its own tier?

Without vswap, if you set zswap as its own tier, which phys swap device should we allocate from for the backing slot? :)

With vswap then it makes sense (and would probably be the "default" for zswap setup until we enable zswap writeback).

Quoted 11 lines · Nhat Pham

Quoted 8 lines · Yosry Ahmed

Quoted 4 lines · Nhat Pham

TBH, without vswap, we should not allow setting zswap as its own tier. It's meaningless. Maybe makes it a no-op, and warn users what they're setting is gibberish?

Why? vswap is transparent to the user. Why can't zswap be its own tier?

Quoted 2 lines

Without vswap, if you set zswap as its own tier, which phys swap device should we allocate from for the backing slot? :)

Today we just allocate a swap slot in a swapfile during reclaim, before swapout, and zswap will just writeback to that one. I assume the same will work with swap tiering, except that maybe the way that swap slot will respect the allowed swap tiers?

Quoted 16 lines · Yosry Ahmed

Quoted 13 lines · Nhat Pham

Quoted 8 lines · Yosry Ahmed

Quoted 4 lines · Nhat Pham

TBH, without vswap, we should not allow setting zswap as its own tier. It's meaningless. Maybe makes it a no-op, and warn users what they're setting is gibberish?

Why? vswap is transparent to the user. Why can't zswap be its own tier?

Without vswap, if you set zswap as its own tier, which phys swap device should we allocate from for the backing slot? :)

Quoted 4 lines

Today we just allocate a swap slot in a swapfile during reclaim, before swapout, and zswap will just writeback to that one. I assume the same will work with swap tiering, except that maybe the way that swap slot will respect the allowed swap tiers?

Yep! So if we set zswap as the only tier, then it wouldn't be able to allocate a swap slot in swapfile right?

Or are you suggesting that if we set zswap as the only tier then we can allocate from any swapfile (since we're not doing any IO anyway)?

On Tue, Jun 16, 2026 at 1:24 PM Nhat Pham <[email protected]> wrote:

Ohh I thought you meant we shouldn't allow zswap to be a tier at all, not the *only* tier.

Quoted 2 lines

Or are you suggesting that if we set zswap as the only tier then we can allocate from any swapfile (since we're not doing any IO anyway)?

Hmm, technically having zswap as the only tier should be equivalent to disabling writeback, but you're right that if zswap is the only tier than the memcg is not allowed to use swap slots from any swapfile, so zswap cannot be used. Very good point :)

In this case I think yes, we need vswap to be enabled to allow making zswap the only tier. That's one gap between zswap being the only tier and disabling zswap writeback, the former requires vswap while the latter doesn't.

Quoted 7 lines · Yosry Ahmed

Quoted 4 lines

In that case, the internal logic could stay roughly the same rather than counting via a page counter. Something like:

1. Change the interface shell: tier.*.max — allow only 0 ~ max.

What about a single interface as I suggested to remain consistent with memory tiering?

Hello Yosry!

I agree. As I was implementing the interface for seeing feasibility , I reconsidered it. Since swap tiers can be added or removed at runtime, having static memory."tier_name".max files seems unnatural.

A single interface like swap.tiers.max would be better. We can use a flat-keyed format (similar to io.weight. same as you suggested)

echo ["tier_name"] ["0 or max"] > swap.tiers.max

I am now leaning towards this is a better direction than what I initially suggested (memory.swap.tiers and memory.swap.tiers.effective).

Considering other reviews and Shakeel's reply, I will update my swap tier patch accordingly.

From: Hao Jia <[email protected]>

Zswap currently writes back pages to backing swap reactively, triggered either by the shrinker or when the pool reaches its size limit. There is no mechanism to control the amount of writeback for a specific memory cgroup. However, users may want to proactively write back zswap pages, e.g., to free up memory for other applications or to prepare for memory-intensive workloads.

Introduce a "zswap_writeback_only" key to the memory.reclaim cgroup interface. When specified, this key bypasses standard memory reclaim and exclusively performs proactive zswap writeback up to the requested budget. If omitted, the default reclaim behavior remains unchanged.

Example usage:
# Write back 100MB of pages from zswap to the backing swap echo "100M zswap_writeback_only" > memory.reclaim

Note that the actual amount written back may be less than requested due to the zswap second-chance algorithm: referenced entries are rotated on the LRU on the first encounter and only written back on a second pass. If fewer bytes are written back than requested, -EAGAIN is returned, matching the existing memory.reclaim semantics.

Internally, extend user_proactive_reclaim() to parse the new "zswap_writeback_only" token and invoke the dedicated handler. Add zswap_proactive_writeback() to walk the target memcg subtree via the per-memcg writeback cursor, draining per-node zswap LRUs through list_lru_walk_one() with the shrink_memcg_cb() callback.

Suggested-by Yosry Ahmed <[email protected]>

Suggested-by Nhat Pham <[email protected]>

Signed-off-by Hao Jia <[email protected]>

---
 Documentation/admin-guide/cgroup-v2.rst |  18 +++-
 Documentation/admin-guide/mm/zswap.rst  |  11 +-
 include/linux/zswap.h                   |   7 ++
 mm/vmscan.c                             |  14 +++
 mm/zswap.c                              | 138 ++++++++++++++++++++++++
 5 files changed, 185 insertions(+), 3 deletions(-)

Documentation/admin-guide/cgroup-v2.rst +5 -2

index 6efd0095ed99..6564abf0dec5 100644
@@ -1425,9 +1425,10 @@ PAGE_SIZE multiple when read back.
 
 The following nested keys are defined.
 
-	  ==========            ================================
+	  ====================  ==================================================
 	  swappiness            Swappiness value to reclaim with
-	  ==========            ================================
+	  zswap_writeback_only  Only perform proactive zswap writeback
+	  ====================  ==================================================
 
 	Specifying a swappiness value instructs the kernel to perform
 	the reclaim with that swappiness value. Note that this has the

@@ -1437,6 +1438,19 @@ The following nested keys are defined.
 	The valid range for swappiness is [0-200, max], setting
 	swappiness=max exclusively reclaims anonymous memory.
 
+	The zswap_writeback_only key skips ordinary memory reclaim and
+	writes back pages from zswap to the backing swap device until

mm/zswap.c +128 -0

index 73e64a635690..7bcbf788f634 100644
@@ -1679,6 +1679,144 @@ int zswap_load(struct folio *folio)
 	return 0;
 }
 
+/*
+ * Maximum LRU scan limit:
+ * number of entries to scan per page of remaining budget.
+ */
+#define ZSWAP_PROACTIVE_WB_SCAN_RATIO	16UL
+/*
+ * Batch size for proactive writeback:
+ * - As the per-memcg writeback target in the outer memcg loop.
+ * - As the per-walk budget passed to list_lru_walk_one().
+ */
+#define ZSWAP_PROACTIVE_WB_BATCH	128UL
+
+/*
+ * Walk the per-node LRUs of @memcg to write back up to @nr_to_write pages.
+ * Returns the number of pages written back, or -ENOENT if @memcg is a
+ * zombie or has writeback disabled.
+ */
+static long zswap_proactive_shrink_memcg(struct mem_cgroup *memcg,
+					 unsigned long nr_to_write)
+{
+	unsigned long nr_written = 0;
+	int nid;
+
+	if (!mem_cgroup_zswap_writeback_enabled(memcg))
+		return -ENOENT;
+
+	if (!mem_cgroup_online(memcg))
+		return -ENOENT;
+
+	for_each_node_state(nid, N_NORMAL_MEMORY) {
+		bool encountered_page_in_swapcache = false;
+		unsigned long nr_to_scan, nr_scanned = 0;
+
+		/*
+		 * Cap by LRU length: bounds rewalks when referenced
+		 * entries keep rotating to the tail.
+		 */
+		nr_to_scan = list_lru_count_one(&zswap_list_lru, nid, memcg);
+		if (!nr_to_scan)
+			continue;
+
+		/*
+		 * Cap by SCAN_RATIO * remaining budget: bounds scan cost
+		 * to the remaining writeback budget.
+		 */
+		nr_to_scan = min(nr_to_scan,
+				 (nr_to_write - nr_written) * ZSWAP_PROACTIVE_WB_SCAN_RATIO);
+
+		while (nr_scanned < nr_to_scan) {
+			unsigned long nr_to_walk = min(ZSWAP_PROACTIVE_WB_BATCH,
+						       nr_to_scan - nr_scanned);
+
+			if (signal_pending(current))
+				return nr_written;
+
+			/*
+			 * Account for the committed budget rather than the walker's
+			 * actual delta. If the list is emptied concurrently, the
+			 * walker visits nothing and nr_scanned would never advance.
+			 */
+			nr_scanned += nr_to_walk;
+
+			nr_written += list_lru_walk_one(&zswap_list_lru, nid, memcg,
+							&shrink_memcg_cb,
+							&encountered_page_in_swapcache,
+							&nr_to_walk);
+
+			if (nr_written >= nr_to_write)
+				return nr_written;
+			if (encountered_page_in_swapcache)
+				break;
+
+			cond_resched();
+		}
+	}
+
+	return nr_written;
+}
+
+int zswap_proactive_writeback(struct mem_cgroup *memcg,
+			      unsigned long nr_to_writeback)
+{
+	struct mem_cgroup *iter_memcg;
+	unsigned long nr_written = 0;
+	int failures = 0, attempts = 0;
+
+	if (!memcg)
+		return -EINVAL;
+	if (!nr_to_writeback)
+		return 0;
+
+	/*
+	 * Writeback will be aborted with -EAGAIN if we encounter
+	 * the following MAX_RECLAIM_RETRIES times:
+	 * - No writeback-candidate memcgs found in a subtree walk.
+	 * - A writeback-candidate memcg wrote back zero pages.
+	 */
+	while (nr_written < nr_to_writeback) {
+		unsigned long batch_size;
+		long shrunk;
+
+		if (signal_pending(current))
+			return -EINTR;
+
+		iter_memcg = zswap_mem_cgroup_iter(memcg);
+
+		if (!iter_memcg) {
+			/*
+			 * Continue without incrementing failures if we found
+			 * candidate memcgs in the last subtree walk.
+			 */
+			if (!attempts && ++failures == MAX_RECLAIM_RETRIES)
+				return -EAGAIN;
+			attempts = 0;
+			continue;
+		}
+
+		batch_size = min(nr_to_writeback - nr_written,
+				 ZSWAP_PROACTIVE_WB_BATCH);
+		shrunk = zswap_proactive_shrink_memcg(iter_memcg, batch_size);
+		mem_cgroup_put(iter_memcg);
+
+		/* Writeback-disabled or offline: skip without counting. */
+		if (shrunk == -ENOENT)
+			continue;
+
+		++attempts;
+		if (shrunk > 0)

Quoted 64 lines · Hao Jia

From: Hao Jia <[email protected]>

Zswap currently writes back pages to backing swap reactively, triggered either by the shrinker or when the pool reaches its size limit. There is no mechanism to control the amount of writeback for a specific memory cgroup. However, users may want to proactively write back zswap pages, e.g., to free up memory for other applications or to prepare for memory-intensive workloads.

Introduce a "zswap_writeback_only" key to the memory.reclaim cgroup interface. When specified, this key bypasses standard memory reclaim and exclusively performs proactive zswap writeback up to the requested budget. If omitted, the default reclaim behavior remains unchanged.

Example usage:
# Write back 100MB of pages from zswap to the backing swap echo "100M zswap_writeback_only" > memory.reclaim

Note that the actual amount written back may be less than requested due to the zswap second-chance algorithm: referenced entries are rotated on the LRU on the first encounter and only written back on a second pass. If fewer bytes are written back than requested, -EAGAIN is returned, matching the existing memory.reclaim semantics.

Internally, extend user_proactive_reclaim() to parse the new "zswap_writeback_only" token and invoke the dedicated handler. Add zswap_proactive_writeback() to walk the target memcg subtree via the per-memcg writeback cursor, draining per-node zswap LRUs through list_lru_walk_one() with the shrink_memcg_cb() callback.

Suggested-by Yosry Ahmed <[email protected]>

Suggested-by Nhat Pham <[email protected]>

Signed-off-by Hao Jia <[email protected]>

---
  Documentation/admin-guide/cgroup-v2.rst |  18 +++-
  Documentation/admin-guide/mm/zswap.rst  |  11 +-
  include/linux/zswap.h                   |   7 ++
  mm/vmscan.c                             |  14 +++
  mm/zswap.c                              | 138 ++++++++++++++++++++++++
  5 files changed, 185 insertions(+), 3 deletions(-)

Documentation/admin-guide/cgroup-v2.rst +5 -2

index 6efd0095ed99..6564abf0dec5 100644
@@ -1425,9 +1425,10 @@ PAGE_SIZE multiple when read back.
 
  The following nested keys are defined.
 
-	  ==========            ================================
+	  ====================  ==================================================
  	  swappiness            Swappiness value to reclaim with
-	  ==========            ================================
+	  zswap_writeback_only  Only perform proactive zswap writeback
+	  ====================  ==================================================
 
  	Specifying a swappiness value instructs the kernel to perform
  	the reclaim with that swappiness value. Note that this has the

@@ -1437,6 +1438,19 @@ The following nested keys are defined.
  	The valid range for swappiness is [0-200, max], setting
  	swappiness=max exclusively reclaims anonymous memory.
 
+	The zswap_writeback_only key skips ordinary memory reclaim and
+	writes back pages from zswap to the backing swap device until

Documentation/admin-guide/cgroup-v2.rst The following nested keys are defined. · line 1452

Quoted 10 lines

Documentation/admin-guide/cgroup-v2.rst +10 -0

+	the requested amount has been written or no further candidates
+	are found. This is useful to proactively offload cold pages from
+	the zswap pool to the swap device. It is only available if
+	zswap writeback is enabled. zswap_writeback_only cannot be combined
+	with swappiness; specifying both returns -EINVAL.
+
+	Example::
+
+	  # Write back up to 100MB of pages from zswap to the backing swap
+	  echo "100M zswap_writeback_only" > memory.reclaim

memcg folks need to chime in about the interface here. An alternative would be a separate interface (e.g. memory.zswap.do_writeback or memory.zswap.writeback.reclaim or sth).

Quoted 141 lines

mm/zswap.c +133 -0

index 73e64a635690..7bcbf788f634 100644
@@ -1679,6 +1679,144 @@ int zswap_load(struct folio *folio)
  	return 0;
  }
 
+/*
+ * Maximum LRU scan limit:
+ * number of entries to scan per page of remaining budget.
+ */
+#define ZSWAP_PROACTIVE_WB_SCAN_RATIO	16UL
+/*
+ * Batch size for proactive writeback:
+ * - As the per-memcg writeback target in the outer memcg loop.
+ * - As the per-walk budget passed to list_lru_walk_one().
+ */
+#define ZSWAP_PROACTIVE_WB_BATCH	128UL
+
+/*
+ * Walk the per-node LRUs of @memcg to write back up to @nr_to_write pages.
+ * Returns the number of pages written back, or -ENOENT if @memcg is a
+ * zombie or has writeback disabled.
+ */
+static long zswap_proactive_shrink_memcg(struct mem_cgroup *memcg,
+					 unsigned long nr_to_write)
+{
+	unsigned long nr_written = 0;
+	int nid;
+
+	if (!mem_cgroup_zswap_writeback_enabled(memcg))
+		return -ENOENT;
+
+	if (!mem_cgroup_online(memcg))
+		return -ENOENT;
+
+	for_each_node_state(nid, N_NORMAL_MEMORY) {
+		bool encountered_page_in_swapcache = false;
+		unsigned long nr_to_scan, nr_scanned = 0;
+
+		/*
+		 * Cap by LRU length: bounds rewalks when referenced
+		 * entries keep rotating to the tail.
+		 */
+		nr_to_scan = list_lru_count_one(&zswap_list_lru, nid, memcg);
+		if (!nr_to_scan)
+			continue;
+
+		/*
+		 * Cap by SCAN_RATIO * remaining budget: bounds scan cost
+		 * to the remaining writeback budget.
+		 */
+		nr_to_scan = min(nr_to_scan,
+				 (nr_to_write - nr_written) * ZSWAP_PROACTIVE_WB_SCAN_RATIO);
+
+		while (nr_scanned < nr_to_scan) {
+			unsigned long nr_to_walk = min(ZSWAP_PROACTIVE_WB_BATCH,
+						       nr_to_scan - nr_scanned);
+
+			if (signal_pending(current))
+				return nr_written;
+
+			/*
+			 * Account for the committed budget rather than the walker's
+			 * actual delta. If the list is emptied concurrently, the
+			 * walker visits nothing and nr_scanned would never advance.
+			 */
+			nr_scanned += nr_to_walk;
+
+			nr_written += list_lru_walk_one(&zswap_list_lru, nid, memcg,
+							&shrink_memcg_cb,
+							&encountered_page_in_swapcache,
+							&nr_to_walk);
+
+			if (nr_written >= nr_to_write)
+				return nr_written;
+			if (encountered_page_in_swapcache)
+				break;
+
+			cond_resched();
+		}
+	}
+
+	return nr_written;
+}
+
+int zswap_proactive_writeback(struct mem_cgroup *memcg,
+			      unsigned long nr_to_writeback)
+{
+	struct mem_cgroup *iter_memcg;
+	unsigned long nr_written = 0;
+	int failures = 0, attempts = 0;
+
+	if (!memcg)
+		return -EINVAL;
+	if (!nr_to_writeback)
+		return 0;
+
+	/*
+	 * Writeback will be aborted with -EAGAIN if we encounter
+	 * the following MAX_RECLAIM_RETRIES times:
+	 * - No writeback-candidate memcgs found in a subtree walk.
+	 * - A writeback-candidate memcg wrote back zero pages.
+	 */
+	while (nr_written < nr_to_writeback) {
+		unsigned long batch_size;
+		long shrunk;
+
+		if (signal_pending(current))
+			return -EINTR;
+
+		iter_memcg = zswap_mem_cgroup_iter(memcg);
+
+		if (!iter_memcg) {
+			/*
+			 * Continue without incrementing failures if we found
+			 * candidate memcgs in the last subtree walk.
+			 */
+			if (!attempts && ++failures == MAX_RECLAIM_RETRIES)
+				return -EAGAIN;
+			attempts = 0;
+			continue;
+		}
+
+		batch_size = min(nr_to_writeback - nr_written,
+				 ZSWAP_PROACTIVE_WB_BATCH);
+		shrunk = zswap_proactive_shrink_memcg(iter_memcg, batch_size);
+		mem_cgroup_put(iter_memcg);
+
+		/* Writeback-disabled or offline: skip without counting. */
+		if (shrunk == -ENOENT)
+			continue;
+
+		++attempts;
+		if (shrunk > 0)
+			nr_written += shrunk;
+		else if (++failures == MAX_RECLAIM_RETRIES)
+			return -EAGAIN;
+
+		cond_resched();

mm/zswap.c int zswap_load(struct folio *folio) · line 1798

Quoted 5 lines

mm/zswap.c +5 -0

+	}
+
+	return 0;
+}
+

There is a lot of copy+paste from shrink_worker() and shrink_memcg() here. We really should be able to reuse shrink_memcg().

Is the main difference that we are scanning in batches here? I think we can have shrink_memcg() do that too. If anything, it might make the shrinker more efficient. Over-reclaim is ofc a concern, and especially in the zswap_store() path as the overhead can be noticeable. Maybe we can parameterize the batch size based on the code path.

Nhat, what do you think?

Quoted 6 lines

Is the main difference that we are scanning in batches here? I think we can have shrink_memcg() do that too. If anything, it might make the shrinker more efficient. Over-reclaim is ofc a concern, and especially in the zswap_store() path as the overhead can be noticeable. Maybe we can parameterize the batch size based on the code path.

Quoted 1 line

Nhat, what do you think?

Nhat, since we now have the referenced-based second chance algorithm, should we consider doing batch writeback for shrink_memcg() as well?

Of course, we could pass a parameter to control whether batch writeback is needed, so as to preserve the original behavior of shrink_memcg().

Thanks,
Hao

Quoted 222 lines · Yosry Ahmed

Quoted 64 lines · Hao Jia

From: Hao Jia <[email protected]>

Zswap currently writes back pages to backing swap reactively, triggered either by the shrinker or when the pool reaches its size limit. There is no mechanism to control the amount of writeback for a specific memory cgroup. However, users may want to proactively write back zswap pages, e.g., to free up memory for other applications or to prepare for memory-intensive workloads.

Introduce a "zswap_writeback_only" key to the memory.reclaim cgroup interface. When specified, this key bypasses standard memory reclaim and exclusively performs proactive zswap writeback up to the requested budget. If omitted, the default reclaim behavior remains unchanged.

Example usage:
# Write back 100MB of pages from zswap to the backing swap echo "100M zswap_writeback_only" > memory.reclaim

Note that the actual amount written back may be less than requested due to the zswap second-chance algorithm: referenced entries are rotated on the LRU on the first encounter and only written back on a second pass. If fewer bytes are written back than requested, -EAGAIN is returned, matching the existing memory.reclaim semantics.

Internally, extend user_proactive_reclaim() to parse the new "zswap_writeback_only" token and invoke the dedicated handler. Add zswap_proactive_writeback() to walk the target memcg subtree via the per-memcg writeback cursor, draining per-node zswap LRUs through list_lru_walk_one() with the shrink_memcg_cb() callback.

Suggested-by Yosry Ahmed <[email protected]>

Suggested-by Nhat Pham <[email protected]>

Signed-off-by Hao Jia <[email protected]>

---
  Documentation/admin-guide/cgroup-v2.rst |  18 +++-
  Documentation/admin-guide/mm/zswap.rst  |  11 +-
  include/linux/zswap.h                   |   7 ++
  mm/vmscan.c                             |  14 +++
  mm/zswap.c                              | 138 ++++++++++++++++++++++++
  5 files changed, 185 insertions(+), 3 deletions(-)

Documentation/admin-guide/cgroup-v2.rst +5 -2

index 6efd0095ed99..6564abf0dec5 100644
@@ -1425,9 +1425,10 @@ PAGE_SIZE multiple when read back.
 
  The following nested keys are defined.
 
-      ==========            ================================
+      ====================  ==================================================
       swappiness            Swappiness value to reclaim with
-      ==========            ================================
+      zswap_writeback_only  Only perform proactive zswap writeback
+      ====================  ==================================================
 
     Specifying a swappiness value instructs the kernel to perform
     the reclaim with that swappiness value. Note that this has the

@@ -1437,6 +1438,19 @@ The following nested keys are defined.
     The valid range for swappiness is [0-200, max], setting
     swappiness=max exclusively reclaims anonymous memory.
 
+    The zswap_writeback_only key skips ordinary memory reclaim and
+    writes back pages from zswap to the backing swap device until

Documentation/admin-guide/cgroup-v2.rst The following nested keys are defined. · line 1452

Quoted 10 lines

Documentation/admin-guide/cgroup-v2.rst +10 -0

+    the requested amount has been written or no further candidates
+    are found. This is useful to proactively offload cold pages from
+    the zswap pool to the swap device. It is only available if
+    zswap writeback is enabled. zswap_writeback_only cannot be combined
+    with swappiness; specifying both returns -EINVAL.
+
+    Example::
+
+      # Write back up to 100MB of pages from zswap to the backing swap
+      echo "100M zswap_writeback_only" > memory.reclaim

memcg folks need to chime in about the interface here. An alternative would be a separate interface (e.g. memory.zswap.do_writeback or memory.zswap.writeback.reclaim or sth).

Quoted 141 lines

mm/zswap.c +133 -0

index 73e64a635690..7bcbf788f634 100644
@@ -1679,6 +1679,144 @@ int zswap_load(struct folio *folio)
     return 0;
  }
 
+/*
+ * Maximum LRU scan limit:
+ * number of entries to scan per page of remaining budget.
+ */
+#define ZSWAP_PROACTIVE_WB_SCAN_RATIO       16UL
+/*
+ * Batch size for proactive writeback:
+ * - As the per-memcg writeback target in the outer memcg loop.
+ * - As the per-walk budget passed to list_lru_walk_one().
+ */
+#define ZSWAP_PROACTIVE_WB_BATCH    128UL
+
+/*
+ * Walk the per-node LRUs of @memcg to write back up to @nr_to_write pages.
+ * Returns the number of pages written back, or -ENOENT if @memcg is a
+ * zombie or has writeback disabled.
+ */
+static long zswap_proactive_shrink_memcg(struct mem_cgroup *memcg,
+                                     unsigned long nr_to_write)
+{
+    unsigned long nr_written = 0;
+    int nid;
+
+    if (!mem_cgroup_zswap_writeback_enabled(memcg))
+            return -ENOENT;
+
+    if (!mem_cgroup_online(memcg))
+            return -ENOENT;
+
+    for_each_node_state(nid, N_NORMAL_MEMORY) {
+            bool encountered_page_in_swapcache = false;
+            unsigned long nr_to_scan, nr_scanned = 0;
+
+            /*
+             * Cap by LRU length: bounds rewalks when referenced
+             * entries keep rotating to the tail.
+             */
+            nr_to_scan = list_lru_count_one(&zswap_list_lru, nid, memcg);
+            if (!nr_to_scan)
+                    continue;
+
+            /*
+             * Cap by SCAN_RATIO * remaining budget: bounds scan cost
+             * to the remaining writeback budget.
+             */
+            nr_to_scan = min(nr_to_scan,
+                             (nr_to_write - nr_written) * ZSWAP_PROACTIVE_WB_SCAN_RATIO);
+
+            while (nr_scanned < nr_to_scan) {
+                    unsigned long nr_to_walk = min(ZSWAP_PROACTIVE_WB_BATCH,
+                                                   nr_to_scan - nr_scanned);
+
+                    if (signal_pending(current))
+                            return nr_written;
+
+                    /*
+                     * Account for the committed budget rather than the walker's
+                     * actual delta. If the list is emptied concurrently, the
+                     * walker visits nothing and nr_scanned would never advance.
+                     */
+                    nr_scanned += nr_to_walk;
+
+                    nr_written += list_lru_walk_one(&zswap_list_lru, nid, memcg,
+                                                    &shrink_memcg_cb,
+                                                    &encountered_page_in_swapcache,
+                                                    &nr_to_walk);
+
+                    if (nr_written >= nr_to_write)
+                            return nr_written;
+                    if (encountered_page_in_swapcache)
+                            break;
+
+                    cond_resched();
+            }
+    }
+
+    return nr_written;
+}
+
+int zswap_proactive_writeback(struct mem_cgroup *memcg,
+                          unsigned long nr_to_writeback)
+{
+    struct mem_cgroup *iter_memcg;
+    unsigned long nr_written = 0;
+    int failures = 0, attempts = 0;
+
+    if (!memcg)
+            return -EINVAL;
+    if (!nr_to_writeback)
+            return 0;
+
+    /*
+     * Writeback will be aborted with -EAGAIN if we encounter
+     * the following MAX_RECLAIM_RETRIES times:
+     * - No writeback-candidate memcgs found in a subtree walk.
+     * - A writeback-candidate memcg wrote back zero pages.
+     */
+    while (nr_written < nr_to_writeback) {
+            unsigned long batch_size;
+            long shrunk;
+
+            if (signal_pending(current))
+                    return -EINTR;
+
+            iter_memcg = zswap_mem_cgroup_iter(memcg);
+
+            if (!iter_memcg) {
+                    /*
+                     * Continue without incrementing failures if we found
+                     * candidate memcgs in the last subtree walk.
+                     */
+                    if (!attempts && ++failures == MAX_RECLAIM_RETRIES)
+                            return -EAGAIN;
+                    attempts = 0;
+                    continue;
+            }
+
+            batch_size = min(nr_to_writeback - nr_written,
+                             ZSWAP_PROACTIVE_WB_BATCH);
+            shrunk = zswap_proactive_shrink_memcg(iter_memcg, batch_size);
+            mem_cgroup_put(iter_memcg);
+
+            /* Writeback-disabled or offline: skip without counting. */
+            if (shrunk == -ENOENT)
+                    continue;
+
+            ++attempts;
+            if (shrunk > 0)
+                    nr_written += shrunk;
+            else if (++failures == MAX_RECLAIM_RETRIES)
+                    return -EAGAIN;
+
+            cond_resched();

Quoted 9 lines

mm/zswap.c int zswap_load(struct folio *folio) · line 1798

Quoted 5 lines

mm/zswap.c +5 -0

+    }
+
+    return 0;
+}
+

There is a lot of copy+paste from shrink_worker() and shrink_memcg() here. We really should be able to reuse shrink_memcg().

I will do some consolidation and code reuse in the next version.

Quoted 6 lines

Is the main difference that we are scanning in batches here? I think we can have shrink_memcg() do that too. If anything, it might make the shrinker more efficient. Over-reclaim is ofc a concern, and especially in the zswap_store() path as the overhead can be noticeable. Maybe we can parameterize the batch size based on the code path.

Quoted 1 line

Nhat, what do you think?

Nhat, since we now have the referenced-based second chance algorithm, should we consider doing batch writeback for shrink_memcg() as well?

Quoted 10 lines

Quoted 7 lines

Is the main difference that we are scanning in batches here? I think we can have shrink_memcg() do that too. If anything, it might make the shrinker more efficient. Over-reclaim is ofc a concern, and especially in the zswap_store() path as the overhead can be noticeable. Maybe we can parameterize the batch size based on the code path.

Nhat, what do you think?

Nhat, since we now have the referenced-based second chance algorithm, should we consider doing batch writeback for shrink_memcg() as well?

I just take a look at shrink_memcg() and realized it's reclaiming one page at a time. Thanks for the reminder - I hated it.

Please batchify it if it makes your life easier :) We don't reclaim "just one page/object" anywhere else in the reclaim path, Sure, it adds a bit of latency to zswap_store() if we reached cgroup limit, but IMHO if we hit zswap.max limit at zswap_store() time, that is already the slowest of slow path that you should have avoided with proactive reclaim/zswap shrinker in the first place. And, setting zswap.max does not make sense to me in the first place (I can write a whole essay about it).

Quoted 15 lines

Quoted 11 lines

Quoted 8 lines

Is the main difference that we are scanning in batches here? I think we can have shrink_memcg() do that too. If anything, it might make the shrinker more efficient. Over-reclaim is ofc a concern, and especially in the zswap_store() path as the overhead can be noticeable. Maybe we can parameterize the batch size based on the code path.

Nhat, what do you think?

Nhat, since we now have the referenced-based second chance algorithm, should we consider doing batch writeback for shrink_memcg() as well?

I just take a look at shrink_memcg() and realized it's reclaiming one page at a time. Thanks for the reminder - I hated it.

Quoted 8 lines

Please batchify it if it makes your life easier :) We don't reclaim "just one page/object" anywhere else in the reclaim path, Sure, it adds a bit of latency to zswap_store() if we reached cgroup limit, but IMHO if we hit zswap.max limit at zswap_store() time, that is already the slowest of slow path that you should have avoided with proactive reclaim/zswap shrinker in the first place. And, setting zswap.max does not make sense to me in the first place (I can write a whole essay about it).

Should we batchify shrink_memcg() from the shrinker and background writeback, but leave the synchronous zswap_store() path to reclaim one page for this series at least to avoid potential regressions?

I think this change specifically needs more intensive testing (vs the other code paths).

Quoted 24 lines · Yosry Ahmed

Quoted 15 lines

Quoted 11 lines

Quoted 8 lines

Is the main difference that we are scanning in batches here? I think we can have shrink_memcg() do that too. If anything, it might make the shrinker more efficient. Over-reclaim is ofc a concern, and especially in the zswap_store() path as the overhead can be noticeable. Maybe we can parameterize the batch size based on the code path.

Nhat, what do you think?

Nhat, since we now have the referenced-based second chance algorithm, should we consider doing batch writeback for shrink_memcg() as well?

I just take a look at shrink_memcg() and realized it's reclaiming one page at a time. Thanks for the reminder - I hated it.

Quoted 8 lines

Please batchify it if it makes your life easier :) We don't reclaim "just one page/object" anywhere else in the reclaim path, Sure, it adds a bit of latency to zswap_store() if we reached cgroup limit, but IMHO if we hit zswap.max limit at zswap_store() time, that is already the slowest of slow path that you should have avoided with proactive reclaim/zswap shrinker in the first place. And, setting zswap.max does not make sense to me in the first place (I can write a whole essay about it).

Quoted 6 lines

Should we batchify shrink_memcg() from the shrinker and background writeback, but leave the synchronous zswap_store() path to reclaim one page for this series at least to avoid potential regressions?

I think this change specifically needs more intensive testing (vs the other code paths).

I'm fine with having shrink_memcg() takes a batch_size argument for now :)

I suspect not a lot of people invokes the shrink_memcg() synchronous path in zswap store though. Setting zswap.max is hard (as it involves guessing compression ratio ahead of time) and induces quite a bit of overhead (obj_cgroup_may_zswap() does a force flush for every store if you set zswap.max to a value other than 0 and max).

Quoted 33 lines · Nhat Pham

Quoted 24 lines · Yosry Ahmed

Quoted 15 lines

Quoted 11 lines

Quoted 8 lines

Is the main difference that we are scanning in batches here? I think we can have shrink_memcg() do that too. If anything, it might make the shrinker more efficient. Over-reclaim is ofc a concern, and especially in the zswap_store() path as the overhead can be noticeable. Maybe we can parameterize the batch size based on the code path.

Nhat, what do you think?

Nhat, since we now have the referenced-based second chance algorithm, should we consider doing batch writeback for shrink_memcg() as well?

I just take a look at shrink_memcg() and realized it's reclaiming one page at a time. Thanks for the reminder - I hated it.

Quoted 8 lines

Please batchify it if it makes your life easier :) We don't reclaim "just one page/object" anywhere else in the reclaim path, Sure, it adds a bit of latency to zswap_store() if we reached cgroup limit, but IMHO if we hit zswap.max limit at zswap_store() time, that is already the slowest of slow path that you should have avoided with proactive reclaim/zswap shrinker in the first place. And, setting zswap.max does not make sense to me in the first place (I can write a whole essay about it).

Quoted 6 lines

Should we batchify shrink_memcg() from the shrinker and background writeback, but leave the synchronous zswap_store() path to reclaim one page for this series at least to avoid potential regressions?

I think this change specifically needs more intensive testing (vs the other code paths).

Quoted 7 lines

I'm fine with having shrink_memcg() takes a batch_size argument for now :)

I suspect not a lot of people invokes the shrink_memcg() synchronous path in zswap store though. Setting zswap.max is hard (as it involves guessing compression ratio ahead of time) and induces quite a bit of overhead (obj_cgroup_may_zswap() does a force flush for every store if you set zswap.max to a value other than 0 and max).

Yeah I agree, but I just wanna make sure we don't completely kill performance in case anyone is actually doing that.

Regarding the force flush, it's unfortunate that we need to rely on a stat for internal limit checking. It might make sense to use page counters here, which already support hierarchical charging and whatnot. We'll need something similar to the objcg approach to charge sub-pages (or maybe just reuse that somehow?).

Quoted 6 lines

Quoted 5 lines

I suspect not a lot of people invokes the shrink_memcg() synchronous path in zswap store though. Setting zswap.max is hard (as it involves guessing compression ratio ahead of time) and induces quite a bit of overhead (obj_cgroup_may_zswap() does a force flush for every store if you set zswap.max to a value other than 0 and max).

Quoted 8 lines

Yeah I agree, but I just wanna make sure we don't completely kill performance in case anyone is actually doing that.

Regarding the force flush, it's unfortunate that we need to rely on a stat for internal limit checking. It might make sense to use page counters here, which already support hierarchical charging and whatnot. We'll need something similar to the objcg approach to charge sub-pages (or maybe just reuse that somehow?).

Conceptually, I've moved towards not capping zswap.max, and using it only as a binary knob for enablement/disablement :)

It's consuming the same resources it saves, so if we cap memory.max (and swap.max until we have vswap), then we already have isolation. The split between uncompressed/compressed should then be dynamically determined by workload characteristics (working set size, access pattern, compressibility) and service's SLO, and reclaimers (preferably proactive reclaimers) will drive us towards the optimal split/equilibrium.

From: Hao Jia <[email protected]>

Currently, zswap writeback can be triggered by either the pool limit being hit or by the proactive writeback mechanism. However, the existing 'zswpwb' metric in memory.stat and /proc/vmstat counts all written back pages, making it difficult to distinguish between pages written back due to the pool limit and those written back proactively.

Add a new statistic 'zswpwb_proactive' to memory.stat and /proc/vmstat. This counter tracks the number of pages written back due to proactive writeback. This allows users to better monitor and tune the proactive writeback mechanism.

Signed-off-by Hao Jia <[email protected]>

---
 Documentation/admin-guide/cgroup-v2.rst |  4 +++
 include/linux/vm_event_item.h           |  1 +
 mm/memcontrol.c                         |  1 +
 mm/vmstat.c                             |  1 +
 mm/zswap.c                              | 41 ++++++++++++++++++-------
 5 files changed, 37 insertions(+), 11 deletions(-)

Documentation/admin-guide/cgroup-v2.rst +0 -0

index 6564abf0dec5..7d65aef83f7b 100644

Documentation/admin-guide/cgroup-v2.rst +0 -0

          zswap_incomp
                Number of incompressible pages currently stored in zswap
                without compression. These pages could not be compressed to

include/linux/vm_event_item.h +1 -0

index 03fe95f5a020..7a5bee0a20b6 100644
@@ -138,6 +138,7 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
                ZSWPIN,
                ZSWPOUT,
                ZSWPWB,
+               ZSWPWB_PROACTIVE,
 #endif
 #ifdef CONFIG_X86
                DIRECT_MAP_LEVEL2_SPLIT,

mm/memcontrol.c +1 -0

index e205e5de193d..7648b3fd940e 100644
@@ -571,6 +571,7 @@ static const unsigned int memcg_vm_event_stat[] = {
        ZSWPIN,
        ZSWPOUT,
        ZSWPWB,
+       ZSWPWB_PROACTIVE,
 #endif
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
        THP_FAULT_ALLOC,

mm/vmstat.c +1 -0

index f534972f517d..66fd06d1bb01 100644
@@ -1452,6 +1452,7 @@ const char * const vmstat_text[] = {
        [I(ZSWPIN)]                             = "zswpin",
        [I(ZSWPOUT)]                            = "zswpout",
        [I(ZSWPWB)]                             = "zswpwb",
+       [I(ZSWPWB_PROACTIVE)]                   = "zswpwb_proactive",
 #endif
 #ifdef CONFIG_X86
        [I(DIRECT_MAP_LEVEL2_SPLIT)]            = "direct_map_level2_splits",

mm/zswap.c +7 -1

index 7bcbf788f634..b45d094f532a 100644
@@ -160,6 +160,11 @@ struct zswap_pool {
        char tfm_name[CRYPTO_MAX_ALG_NAME];
 };
 
+struct zswap_shrink_walk_arg {
+       bool proactive;
+       bool encountered_page_in_swapcache;
+};
+
 /* Global LRU lists shared by all zswap pools. */
 static struct list_lru zswap_list_lru;
 

@@ -1042,7 +1047,8 @@ static bool zswap_decompress(struct zswap_entry *entry, struct folio *folio)
  * freed.
  */
 static int zswap_writeback_entry(struct zswap_entry *entry,
-                                swp_entry_t swpentry)
+                                swp_entry_t swpentry,
+                                bool proactive)
 {
        struct xarray *tree;
        pgoff_t offset = swp_offset(swpentry);

Quoted 28 lines · Hao Jia

From: Hao Jia <[email protected]>

Currently, zswap writeback can be triggered by either the pool limit being hit or by the proactive writeback mechanism. However, the existing 'zswpwb' metric in memory.stat and /proc/vmstat counts all written back pages, making it difficult to distinguish between pages written back due to the pool limit and those written back proactively.

Add a new statistic 'zswpwb_proactive' to memory.stat and /proc/vmstat. This counter tracks the number of pages written back due to proactive writeback. This allows users to better monitor and tune the proactive writeback mechanism.

Signed-off-by Hao Jia <[email protected]>

---
  Documentation/admin-guide/cgroup-v2.rst |  4 +++
  include/linux/vm_event_item.h           |  1 +
  mm/memcontrol.c                         |  1 +
  mm/vmstat.c                             |  1 +
  mm/zswap.c                              | 41 ++++++++++++++++++-------
  5 files changed, 37 insertions(+), 11 deletions(-)

Documentation/admin-guide/cgroup-v2.rst +0 -0

index 6564abf0dec5..7d65aef83f7b 100644

Documentation/admin-guide/cgroup-v2.rst The following nested keys are defined. · line 1754

Quoted 7 lines

Documentation/admin-guide/cgroup-v2.rst +4 -0

@@ -1748,6 +1748,10 @@ The following nested keys are defined.
           zswpwb
                 Number of pages written from zswap to swap.
 
+         zswpwb_proactive
+               Number of pages written from zswap to swap by proactive
+               writeback. This is a subset of zswpwb.
+

nit: I think this is specifically the zswap_writeback_only mode right?

Technically, normal proactive reclaim (memory.reclaim) can also hit zswap :)

Maybe some clarification here?

From: Hao Jia <[email protected]>

Add test_zswap_proactive_writeback() to cover the new memory.reclaim "zswap_writeback_only" key. The test populates a memory cgroup zswap pool, triggers proactive writeback, and verifies the behavior by observing the change in zswpwb_proactive. Invalid input combinations are also covered.

Extend test_zswap_writeback_one() to assert that the existing non-proactive writeback path leaves zswpwb_proactive at zero.

Signed-off-by Hao Jia <[email protected]>