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 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. > swpout_zero > 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?
