linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Yosry Ahmed <yosryahmed@google.com>
To: Nhat Pham <nphamcs@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	 Chengming Zhou <chengming.zhou@linux.dev>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] mm: zswap: remove nr_zswap_stored atomic
Date: Thu, 21 Mar 2024 16:57:27 -0700	[thread overview]
Message-ID: <CAJD7tkaC5eTe8Os6f0VsGx9o06YE8zX1r0R0PPMvExRfcGhPgg@mail.gmail.com> (raw)
In-Reply-To: <CAKEwX=PjpJCewYEMp+=g+92=R-Wr2y+7pwJ81xb9-pogohFC4w@mail.gmail.com>

On Thu, Mar 21, 2024 at 4:50 PM Nhat Pham <nphamcs@gmail.com> wrote:
>
> On Thu, Mar 21, 2024 at 2:09 PM Yosry Ahmed <yosryahmed@google.com> wrote:
> >
> > On Tue, Mar 19, 2024 at 7:08 PM Yosry Ahmed <yosryahmed@google.com> wrote:
> > >
> > > zswap_nr_stored is used to maintain the number of stored pages in zswap
> > > that are not same-filled pages. It is used in zswap_shrinker_count() to
> > > scale the number of freeable compressed pages by the compression ratio.
> > > That is, to reduce the amount of writeback from zswap with higher
> > > compression ratios as the ROI from IO diminishes.
> > >
> > > However, the need for this counter is questionable due to two reasons:
> > > - It is redundant. The value can be inferred from (zswap_stored_pages -
> > >   zswap_same_filled_pages).
>
> Ah, I forgot about this. For context, nr_stored was originally a
> zswap_pool-specific stat, but I think Chengming has pulled it out and
> converted it into a global pool stat in an earlier patch - yet,
> globally, we already have zswap_stored_pages that is (mostly) the same
> counter.

Thanks for the context.

>
> Might as well use existing counters (zswap_stored_pages) then, rather
> than a newly introduced counter. Probably will shave off a couple
> cycles here and there for the atomic increment/decrement :)
>
> > > - When memcgs are enabled, we use memcg_page_state(memcg,
> > >   MEMCG_ZSWAPPED), which includes same-filled pages anyway (i.e.
> > >   equivalent to zswap_stored_pages).
>
> This is fine I suppose. I was aware of this weird inaccuracy. However,
> for the CONFIG_MEMCG case, it was kinda silly to introduce the counter
> for per-cgroup same filled zswap pages, just for this one purpose, so
> I decided to accept the inaccuracy.
>
> > >
> > > Use zswap_stored_pages instead in zswap_shrinker_count() to keep things
> > > consistent whether memcgs are enabled or not, and add a comment about
> > > the number of freeable pages possibly being scaled down more than it
> > > should if we have lots of same-filled pages (i.e. inflated compression
> > > ratio).
> > >
> > > Remove nr_zswap_stored and one atomic operation in the store and free
> > > paths.
> > >
> > > Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
> >
> > Any thoughts on this patch? Should I resend it separately?
>
> Might be worth resending it separately, but up to you and Andrew!

I will resend to add some context and include your R-b, thanks.

>
> Reviewed-by: Nhat Pham <nphamcs@gmail.com>


  reply	other threads:[~2024-03-21 23:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-20  2:08 [PATCH 1/2] mm: zswap: increase shrinking protection for zswap swapins only Yosry Ahmed
2024-03-20  2:08 ` [PATCH 2/2] mm: zswap: remove nr_zswap_stored atomic Yosry Ahmed
2024-03-21 21:09   ` Yosry Ahmed
2024-03-21 23:50     ` Nhat Pham
2024-03-21 23:57       ` Yosry Ahmed [this message]
2024-03-20  9:50 ` [PATCH 1/2] mm: zswap: increase shrinking protection for zswap swapins only Johannes Weiner
2024-03-20 14:48   ` Nhat Pham
2024-03-20 19:32     ` Yosry Ahmed
2024-03-20 19:28   ` Yosry Ahmed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJD7tkaC5eTe8Os6f0VsGx9o06YE8zX1r0R0PPMvExRfcGhPgg@mail.gmail.com \
    --to=yosryahmed@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=chengming.zhou@linux.dev \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nphamcs@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox