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

[Barry Song]

On Wed, Feb 25, 2026 at 8:34 PM Kairui Song <ryncsn@xxxxxxxxx> wrote:
>
> On Wed, Feb 25, 2026 at 8:19 PM Barry Song <21cnbao@xxxxxxxxx> wrote:
> >
> > On Fri, Feb 20, 2026 at 7:42 AM Kairui Song via B4 Relay
> > <devnull+kasong.tencent.com@xxxxxxxxxx> wrote:
> > >
> > > From: Kairui Song <kasong@xxxxxxxxxxx>
> > >
> > > 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.

I did notice that some cache data has been consolidated from two
places—the swap table and the zeromap—into a single location.
However, swap_zeromap_batch() previously operated on a bitmap,
whereas it now accesses multiple data. Is that also
expected to be fine?

Thanks
Barry