Re: [PATCH v4 09/19] mm, swap: swap entry of a bad slot should not be considered as swapped out

From: Kairui Song

Date: Sun Dec 14 2025 - 23:12:53 EST


On Mon, Dec 15, 2025 at 11:57 AM Baoquan He <bhe@xxxxxxxxxx> wrote:
>
> On 12/05/25 at 03:29am, Kairui Song wrote:
> > From: Kairui Song <kasong@xxxxxxxxxxx>
> >
> > When checking if a swap entry is swapped out, we simply check if the
> > bitwise result of the count value is larger than 0. But SWAP_MAP_BAD
> > will also be considered as a swao count value larger than 0.
> >
> > SWAP_MAP_BAD being considered as a count value larger than 0 is useful
> > for the swap allocator: they will be seen as a used slot, so the
> > allocator will skip them. But for the swapped out check, this
> > isn't correct.
> >
> > There is currently no observable issue. The swapped out check is only
> > useful for readahead and folio swapped-out status check. For readahead,
> > the swap cache layer will abort upon checking and updating the swap map.
> > For the folio swapped out status check, the swap allocator will never
> > allocate an entry of bad slots to folio, so that part is fine too. The
> > worst that could happen now is redundant allocation/freeing of folios
> > and waste CPU time.
> >
> > This also makes it easier to get rid of swap map checking and update
> > during folio insertion in the swap cache layer.
>
> Will swap_entry_swapped() be called in other places in phase 3 of swap
> table?

This function might get less called or even removed in the future.
When the swap table is fully ready, checking the table directly is
cheaper and simpler. I checked my local phase 3 code and there is only
one caller left now.

>
> I checked the code of the current phase 2, in all three places you
> convert it with swp_offset(entry), is it necessary? Why don't you keep
> the swap_entry_swapped(si, entry)? Surely, this is trivial.

Right, might be a good idea to just keep it as it is to make the
review easier. I thought the `entry` is a little bit redundant with
the si parameter, the type info in it is not needed at all, so using
offset instead may save a few CPU cycles while at it. Really trivial
indeed, I can change it back if there is another update of the series.

Anyway, thanks for the review.