Re: [PATCH v4 01/15] docs/mm: add document for swap table

[Chris Li <chrisl@kernel.org>]

On Tue, Sep 16, 2025 at 4:09 PM Barry Song <21cnbao@gmail.com> wrote:
> > I think my previous statement still stands correct considering both
> > swap out and swap in. Of course there is always room for improvement
> > to make it more clear. But folio always has the data is not true for
> > swap in. If you have other ways to improve it, please feel free to
> > suggest.
>
> I assume you’re referring to the swapin case where a folio has been
> allocated and added to the swap cache, but it’s still being read and
> hasn’t been updated yet?

Right. That is the case swapfile has the data and folio does not.

>
> I assume it could be something like:
> The data may be in the folio or will be placed there later. It could
This is for swap in only, does not describe the swap out case.

> also reside in the swap file.

Right and it did not have the same coverage about data that can be
both in the folio and swapfile. Sorry about the pedantic. If we want
to improve it, we might want to cover the same level of detail.

> Alternatively, leave it unchanged.
I think considering the swap out and swap in case, the original is
fine. The reader will need to make some effort to map to what it does
in the code, at least the description is correct.

>
> >
> >
> > > On a 32-bit system, I’m guessing the swap table is 2 KB, which is about
> > > half of a page?
> >
> > Yes, true. I consider that but decide to leave it out of the document.
> > There are a lot of other implementation details the document does not
> > cover, not just this aspect. This document provides a simple
> > abstracted view (might not cover all the detail cases). One way to
> > address that is add a qualification "on a 64 bit system". What do you
> > say? I don't want to talk about the 32 bit system having half of a
> > page in this document, I consider that too much detail. The 32 bit
> > system is pretty rare nowadays.
>
> I’d prefer that we remove all descriptions about matching PAGE_SIZE,

I am fine with that as well.

> since we would need to double-check every case, like 16 KB or 64 KB pages.

The cluster size is determined by the last to second level page table
page size. I fail to see why 16KB matters here for the cluster. Are
you saying in the 16KB page size case, the custer size is 512/4 = 128
swap entry per cluster?

> For ARM64 with a 16 KB page size, the last-level index uses 24:14.
> For ARM64 with a 64 KB page size, it uses 28:16[1]. For them, 512 entries
> are not one PAGE.

Now you got me curioused.

In your above two examples, what is the respected swap cluster swap entry size?
In other words, how much entry does one swap cluster hold?

Sorry I am not very familiar with the ARM page tables.

Chris