Re: [PATCH RFC 12/15] mm, swap: merge zeromap into swap table

[Kairui Song <ryncsn@gmail.com>]

On Wed, Feb 25, 2026 at 8:19 PM Barry Song <21cnbao@gmail.com> wrote:
>
> On Fri, Feb 20, 2026 at 7:42 AM Kairui Song via B4 Relay
> <devnull+kasong.tencent.com@kernel.org> wrote:
> >
> > From: Kairui Song <kasong@tencent.com>
> >
> > By reserving one bit for the counting part, we can easily merge the
> > zeromap into the swap table.
>
>
> Hi Kairui,
>
> I know you're saving space by removing the zeromap memory,
> but do you think a bitmap can sometimes be faster
> than iterating over multiple data points to set or get bits?
> Or is the performance difference too small to notice?
>
> Thanks
> Barry
>

Hi Barry,

It might be even faster this way. Swap table / swap cache is the same
core data and must be touched upon swapout / swapin, if the bit is
also in the swap table, then it could save a cache miss.
Also slightly reduce memory pressure.

For swapin, __swap_cache_check_batch now checks the bit with things
like memcg info in the same place, and everyinfo is in the swap table.
Currently it uses two loops in this RFC version but can be merged into
one loop. Even with two loops it should be more cache friendly.

And "clear_bit(offset + i, si->zeromap)" is just gone, because
setting the NULL entry also clears the bit.

Page io accesses the bit in the swap table separately, but the timing
is close to swap table update so probably it's also beneficial to the
cache.

So I think it might be even faster, or at least the performance
difference is too trivial to notice, I did some tests, and didn't
observe any difference.