Re: [PATCH v6] zswap: memcontrol: implement zswap writeback disabling (fix)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Nhat,

Acked-by: Chris Li <chrisl@xxxxxxxxxx>

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@xxxxxxxxx> wrote:
>
> Add a caveat about recurring zswap store failures leading to reclaim
> inefficiency.
>
> Suggested-by: Yosry Ahmed <yosryahmed@xxxxxxxxxx>
> Signed-off-by: Nhat Pham <nphamcs@xxxxxxxxx>
> ---
>  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
>





[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux