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

[Barry Song <21cnbao@gmail.com>]

On Wed, Sep 17, 2025 at 7:29 AM Chris Li <chrisl@kernel.org> wrote:
>
> 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.

Ok.

>
> >
> > >
> > >
> > > > 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.

Oh, my mistake—I recalculated:

For a 16 KB page size, SWAPCLUSTER_SIZE will be 2^11 = 2048, so the swap
table is 2048 * 8 = 16 KB.
For a 64 KB page size, SWAPCLUSTER_SIZE will be 2^13 = 8192, so the swap
table is 8192 * 8 = 64 KB.

This approach still seems to work, so the 32-bit system appears to be
the only exception. However, I’m not entirely sure that your description
of “the second last level” is correct. I believe it refers to the PTE,
which corresponds to the last level, not the second-to-last.
In other words, how do you define the second-to-last level page table?

Thanks
Barry