[v6] zswap: memcontrol: implement zswap writeback disabling (fix)
Commit Message
Add a caveat about recurring zswap store failures leading to reclaim
inefficiency.
Suggested-by: Yosry Ahmed <yosryahmed@google.com>
Signed-off-by: Nhat Pham <nphamcs@gmail.com>
---
Documentation/admin-guide/cgroup-v2.rst | 5 ++++-
Documentation/admin-guide/mm/zswap.rst | 4 ++++
2 files changed, 8 insertions(+), 1 deletion(-)
Comments
Hi Nhat,
Acked-by: Chris Li <chrisl@kernel.org>
I think a follow up step would be having some patches to address it
rather than document it that oh yes, we have a problem in that
situation.
Chris
On Wed, Dec 20, 2023 at 4:57 PM Nhat Pham <nphamcs@gmail.com> wrote:
>
> Add a caveat about recurring zswap store failures leading to reclaim
> inefficiency.
>
> Suggested-by: Yosry Ahmed <yosryahmed@google.com>
> Signed-off-by: Nhat Pham <nphamcs@gmail.com>
> ---
> Documentation/admin-guide/cgroup-v2.rst | 5 ++++-
> Documentation/admin-guide/mm/zswap.rst | 4 ++++
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
> index 2b4ac43efdc8..5ec7dd753cd1 100644
> --- a/Documentation/admin-guide/cgroup-v2.rst
> +++ b/Documentation/admin-guide/cgroup-v2.rst
> @@ -1686,7 +1686,10 @@ PAGE_SIZE multiple when read back.
>
> When this is set to 0, all swapping attempts to swapping devices
> are disabled. This included both zswap writebacks, and swapping due
> - to zswap store failure.
> + to zswap store failures. If the zswap store failures are recurring
> + (for e.g if the pages are incompressible), users can observe
> + reclaim inefficiency after disabling writeback (because the same
> + pages might be rejected again and again).
>
> Note that this is subtly different from setting memory.swap.max to
> 0, as it still allows for pages to be written to the zswap pool.
> diff --git a/Documentation/admin-guide/mm/zswap.rst b/Documentation/admin-guide/mm/zswap.rst
> index cfa653130346..b42132969e31 100644
> --- a/Documentation/admin-guide/mm/zswap.rst
> +++ b/Documentation/admin-guide/mm/zswap.rst
> @@ -159,6 +159,10 @@ zswap itself) on a cgroup-basis as follows:
>
> echo 0 > /sys/fs/cgroup/<cgroup-name>/memory.zswap.writeback
>
> +Note that if the store failures are recurring (for e.g if the pages are
> +incompressible), users can observe reclaim inefficiency after disabling
> +writeback (because the same pages might be rejected again and again).
> +
> When there is a sizable amount of cold memory residing in the zswap pool, it
> can be advantageous to proactively write these cold pages to swap and reclaim
> the memory for other use cases. By default, the zswap shrinker is disabled.
> --
> 2.34.1
>
@@ -1686,7 +1686,10 @@ PAGE_SIZE multiple when read back.
When this is set to 0, all swapping attempts to swapping devices
are disabled. This included both zswap writebacks, and swapping due
- to zswap store failure.
+ to zswap store failures. If the zswap store failures are recurring
+ (for e.g if the pages are incompressible), users can observe
+ reclaim inefficiency after disabling writeback (because the same
+ pages might be rejected again and again).
Note that this is subtly different from setting memory.swap.max to
0, as it still allows for pages to be written to the zswap pool.
@@ -159,6 +159,10 @@ zswap itself) on a cgroup-basis as follows:
echo 0 > /sys/fs/cgroup/<cgroup-name>/memory.zswap.writeback
+Note that if the store failures are recurring (for e.g if the pages are
+incompressible), users can observe reclaim inefficiency after disabling
+writeback (because the same pages might be rejected again and again).
+
When there is a sizable amount of cold memory residing in the zswap pool, it
can be advantageous to proactively write these cold pages to swap and reclaim
the memory for other use cases. By default, the zswap shrinker is disabled.