Re: [PATCH] mm: zswap: shrink until can accept

[Domenico Cerasuolo]

On Sat, May 27, 2023 at 1:05 AM Chris Li <chrisl@xxxxxxxxxx> wrote:
>
> On Wed, May 24, 2023 at 08:50:51AM +0200, Domenico Cerasuolo wrote:
> > This update addresses an issue with the zswap reclaim mechanism, which
> > hinders the efficient offloading of cold pages to disk, thereby
> > compromising the preservation of the LRU order and consequently
> > diminishing, if not inverting, its performance benefits.
> >
> > The functioning of the zswap shrink worker was found to be inadequate,
> > as shown by basic benchmark test. For the test, a kernel build was
> > utilized as a reference, with its memory confined to 1G via a cgroup and
> > a 5G swap file provided. The results are presented below, these are
> > averages of three runs without the use of zswap:
> >
> > real 46m26s
> > user 35m4s
> > sys 7m37s
> >
> > With zswap (zbud) enabled and max_pool_percent set to 1 (in a 32G
> > system), the results changed to:
> >
> > real 56m4s
> > user 35m13s
> > sys 8m43s
> >
> > written_back_pages: 18
> > reject_reclaim_fail: 0
> > pool_limit_hit:1478
> >
> > Besides the evident regression, one thing to notice from this data is
> > the extremely low number of written_back_pages and pool_limit_hit.
> >
> > The pool_limit_hit counter, which is increased in zswap_frontswap_store
> > when zswap is completely full, doesn't account for a particular
> > scenario: once zswap hits his limit, zswap_pool_reached_full is set to
> > true; with this flag on, zswap_frontswap_store rejects pages if zswap is
> > still above the acceptance threshold. Once we include the rejections due
> > to zswap_pool_reached_full && !zswap_can_accept(), the number goes from
> > 1478 to a significant 21578266.
> >
> > Zswap is stuck in an undesirable state where it rejects pages because
> > it's above the acceptance threshold, yet fails to attempt memory
> > reclaimation. This happens because the shrink work is only queued when
> > zswap_frontswap_store detects that it's full and the work itself only
> > reclaims one page per run.
> >
> > This state results in hot pages getting written directly to disk,
> > while cold ones remain memory, waiting only to be invalidated. The LRU
> > order is completely broken and zswap ends up being just an overhead
> > without providing any benefits.
> >
> > This commit applies 2 changes: a) the shrink worker is set to reclaim
> > pages until the acceptance threshold is met and b) the task is also
> > enqueued when zswap is not full but still above the threshold.
> >
> > Testing this suggested update showed much better numbers:
> >
> > real 36m37s
> > user 35m8s
> > sys 9m32s
> >
> > written_back_pages: 10459423
> > reject_reclaim_fail: 12896
> > pool_limit_hit: 75653
> >
> > Fixes: 45190f01dd40 ("mm/zswap.c: add allocation hysteresis if pool limit is hit")
> > Signed-off-by: Domenico Cerasuolo <cerasuolodomenico@xxxxxxxxx>
> > ---
> >  mm/zswap.c | 10 +++++++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/mm/zswap.c b/mm/zswap.c
> > index 59da2a415fbb..2ee0775d8213 100644
> > --- a/mm/zswap.c
> > +++ b/mm/zswap.c
> > @@ -587,9 +587,13 @@ static void shrink_worker(struct work_struct *w)
> >  {
> >       struct zswap_pool *pool = container_of(w, typeof(*pool),
> >                                               shrink_work);
> > +     int ret;
> Very minor nit pick, you can move the declare inside the do
> statement where it get used.
>
> >
> > -     if (zpool_shrink(pool->zpool, 1, NULL))
> > -             zswap_reject_reclaim_fail++;
> > +     do {
> > +             ret = zpool_shrink(pool->zpool, 1, NULL);
> > +             if (ret)
> > +                     zswap_reject_reclaim_fail++;
> > +     } while (!zswap_can_accept() && ret != -EINVAL);
>
> As others point out, this while loop can be problematic.

Do you have some specific concern that's not been already addressed following
other reviewers' suggestions?

>
> Have you find out what was the common reason causing the
> reclaim fail? Inside the shrink function there is a while
> loop that would be the place to perform try harder conditions.
> For example, if all the page in the LRU are already try once
> there's no reason to keep on calling the shrink function.
> The outer loop actually doesn't have this kind of visibilities.
>

The most common cause I saw during testing was concurrent operations
on the swap entry, if an entry is being loaded/invalidated at the same time
as the zswap writeback, then errors will be returned. This scenario doesn't
seem harmful at all because the failure doesn't indicate that memory
cannot be allocated, just that that particular page should not be written back.

As far as I understood the voiced concerns, the problem could arise if the
writeback fails due to an impossibility to allocate memory, that could indicate
that the system is in extremely high memory pressure and this loop could
aggravate the situation by adding more contention on the already scarce
available memory.

Since both these cases are treated equally with the retries limit, we're
adopting a conservative approach in considering non-harmful errors as if
they were harmful. This could certainly be improved, but I don't see it as an
issue because a differentiation of the errors would actually make the loop run
longer than it would without the differentiation.

As I was writing to Yosry, the differentiation would be a great improvement
here, I just have a patch set in the queue that moves the inner reclaim loop
from the zpool driver up to zswap. With that, updating the error handling
would be more convenient as it would be done in one place instead of three.

>
> Chris
>
> >       zswap_pool_put(pool);
> >  }
> >
> > @@ -1188,7 +1192,7 @@ static int zswap_frontswap_store(unsigned type, pgoff_t offset,
> >       if (zswap_pool_reached_full) {
> >              if (!zswap_can_accept()) {
> >                       ret = -ENOMEM;
> > -                     goto reject;
> > +                     goto shrink;
> >               } else
> >                       zswap_pool_reached_full = false;
> >       }
> > --
> > 2.34.1
> >