Re: [RFC PATCH 02/11] mm, swap: add CONFIG_XSWAP and xswap fields to swap_info_struct

[Baoquan He <baoquan.he@linux.dev>]

On 07/27/26 at 08:26am, Chris Li wrote:
> On Mon, Jul 27, 2026 at 7:05 AM Baoquan He <baoquan.he@linux.dev> wrote:
> >
> > Add CONFIG_XSWAP Kconfig option (depends on SWAP && 64BIT) for
> > extendable (virtual) swap device support.
> >
> > Add three fields to struct swap_info_struct under CONFIG_XSWAP:
> > - cluster_vm: the VM_SPARSE vm_struct backing the cluster_info array
> > - nr_clusters: total number of clusters in the xswap address space
> > - nr_clusters_mapped: number of clusters currently mapped (lazy grow)
> >
> > These fields enable lazy vmalloc-based dynamic cluster management
> > where the cluster_info array is backed by a sparse vmalloc area that
> > grows on demand and shrinks when clusters are freed.
> >
> > Signed-off-by: Baoquan He <baoquan.he@linux.dev>
> > ---
> >  include/linux/swap.h | 5 +++++
> >  mm/Kconfig           | 9 +++++++++
> >  2 files changed, 14 insertions(+)
> >
> > diff --git a/include/linux/swap.h b/include/linux/swap.h
> > index 80c83dd8804f..5f6b14d30758 100644
> > --- a/include/linux/swap.h
> > +++ b/include/linux/swap.h
> > @@ -248,6 +248,11 @@ struct swap_info_struct {
> >         signed char     type;           /* strange name for an index */
> >         unsigned int    max;            /* size of this swap device */
> >         struct swap_cluster_info *cluster_info; /* cluster info. Only for SSD */
> > +#ifdef CONFIG_XSWAP
> > +       struct vm_struct        *cluster_vm;    /* VM_SPARSE area for xswap dynamic cluster_info */
> > +       unsigned long           nr_clusters;    /* total cluster count for xswap */
> > +       unsigned long           nr_clusters_mapped; /* currently mapped cluster count */
> > +#endif
> 
> We might need more than one dynamic kvmalloc grow array. Maybe
> abstract this into a struct so it can be reused for arrays other than
> clusters as well. The abstraction can also include the element size so
> it can have a generic function to calculate how many pages it needs
> for N elements.

I agree in principle. I think we can pull that out as a follow-up when
the second user emerges, rather than abstracting prematurely.