On Mon, Nov 04, 2024 at 01:42:08PM +0100, David Hildenbrand wrote:
On 02.11.24 11:12, Barry Song wrote:
@@ -1599,6 +1599,16 @@ The following nested keys are defined.
pglazyfreed (npn)
Amount of reclaimed lazyfree pages
+ swpin_zero
+ Number of pages moved into memory with zero content, meaning no
+ copy exists in the backend swapfile, allowing swap-in to avoid
+ I/O read overhead.
+
+ swpout_zero
+ Number of pages moved out of memory with zero content, meaning no
+ copy is needed in the backend swapfile, allowing swap-out to avoid
+ I/O write overhead.
Hm, can make it a bit clearer that this is a pure optimization and refer
to the other counters?
swpin_zero
Portion of "pswpin" pages for which I/O was optimized out
because the page content was detected to be zero during swapout.
AFAICS the zeropages currently don't show up in pswpin/pswpout, so
these are independent counters, not subsets.
I'm leaning towards Barry's side on the fixes tag.
When zswap handled> >> swpout_zero
the same-filled pages, we would count them in zswpin/out. From a user
POV, especially one using zswap, the behavior didn't change, but the
counts giving insight into this (potentially significant) VM activity
disappeared. This is arguably a regression.
Portion of "pswout" pages for which I/O was optimized out
because the page content was detected to be zero.
Are we sure we want to commit to the "zero" in the name here? Until
very recently, zswap optimized all same-filled pages. It's possible
somebody might want to bring that back down the line.
In reference to the above, I'd actually prefer putting them back into
zswpin/zswpout. Sure, they're not handled by zswap.c proper, but this
is arguably just an implementation detail; from a user POV this is
still just (a form of) compression in lieu of IO to the swap backend.
IMO there is no need for coming up with a separate category. Just add
them to zswpin/zswpout and remove the CONFIG_ZSWAP guards from them?