Messages in this thread |  | | From | Nhat Pham <> | | Date | Sat, 11 Apr 2026 18:03:04 -0700 | | Subject | Re: [PATCH v5 00/21] Virtual Swap Space |
| |
On Wed, Mar 25, 2026 at 11:53 AM YoungJun Park <youngjun.park@lge.com> wrote: > > On Mon, Mar 23, 2026 at 11:32:57AM -0400, Nhat Pham wrote: > > > Interesting. Normally "lots of zero-filled page" is a very beneficial > > case for vswap. You don't need a swapfile, or any zram/zswap metadata > > overhead - it's a native swap backend. If production workload has this > > many zero-filled pages, I think the numbers of vswap would be much > > less alarming - perhaps even matching memory overhead because you > > don't need to maintain a zram entry metadata (it's at least 2 words > > per zram entry right?), while there's no reverse map overhead induced > > (so it's 24 bytes on both side), and no need to do zram-side locking > > :) > > > > So I was surprised to see that it's not working out very well here. I > > checked the implementation of memhog - let me know if this is wrong > > place to look: > > > > https://man7.org/linux/man-pages/man8/memhog.8.html > > https://github.com/numactl/numactl/blob/master/memhog.c#L52 > > > > I think this is what happened here: memhog was populating the memory > > 0xff, which triggers the full overhead of a swapfile-backed swap entry > > because even though it's "same-filled" it's not zero-filled! I was > > following Usama's observation - "less than 1% of the same-filled pages > > were non-zero" - and so I only handled the zero-filled case here: > > > > https://lore.kernel.org/all/20240530102126.357438-1-usamaarif642@gmail.com/ > > > > This sounds a bit artificial IMHO - as Usama pointed out above, I > > think most samefilled pages are zero pages, in real production > > workloads. However, if you think there are real use cases with a lot > > of non-zero samefilled pages, please let me know I can fix this real > > quick. We can support this in vswap with zero extra metadata overhead > > - change the VSWAP_ZERO swap entry type to VSWAP_SAME_FILLED, then use > > the backend field to store that value. I can send you a patch if > > you're interested. > > This brings back memories -- I'm pretty sure we talked about > exactly this at LPC. Our custom swap device already handles both > zero-filled and same-filled pages on its own, so what we really > wanted was a way to tell the swap layer "just skip the detection > and let it through." > > I looked at two approaches back then but never submitted either: > > - A per-swap_info flag to opt out of zero/same-filled handling. > But this felt wrong from vswap's perspective -- if even one > device opts out of the zeromap, the model gets messy. > > - Revisiting Usama's patch 2 approach. > Sounded good in theory, but as you said, > it's not as simple to verify in practice. And it is more clean design > swapout time zero check as I see. So, I gave up on it. > > Seeing this come up again is actually kind of nice :) > > One thought -- maybe a compile-time CONFIG or a boot param to > control the scope? e.g. zero-only, same-filled, or disabled. > That way vendors like us just turn it off, and setups like > Kairui's can opt into broader detection. Just an idea though -- > open to other approaches if you have something in mind.
Yeah for vswap it's probably going to be a CONFIG or boot param.
But in the status quo, we can always add a swapfile flag. That one should work already, right?
Thanks for thinking about it :) FWIW I think zero check is really cheap, but yeah it's just wasted work.
(ZRAM folks - do you feel the overhead here?)
> > Thanks, > Youngjun Park >
|  |