Re: [PATCH 0/3] mm/swap: use swap_ops to register swap device's methods

[Baoquan He <bhe@redhat.com>]

On 03/02/26 at 11:43pm, YoungJun Park wrote:
> On Mon, Mar 02, 2026 at 06:40:13PM +0800, Baoquan He wrote:
> > This can simplify the code logic and benefit any new type of swap device
> > added later.
> > 
> > And also do renaming in this patchset:
> > -------
> >    file renaming:
> >    ---
> >    mm/page_io.c to mm/swap_io.c
> > 
> >    function renaming:
> >    ---
> >    swap_writepage_* to swap_write_folio_* in file mm/swap_io.c 
> > 
> > 
> > Baoquan He (3):
> >   mm/swap: rename mm/page_io.c to mm/swap_io.c
> >   mm/swap: use swap_ops to register swap device's methods
> >   mm/swap_io.c: rename swap_writepage_* to swap_write_folio_*
> > 
> >  MAINTAINERS                 |   2 +-
> >  include/linux/swap.h        |  13 +++++
> >  mm/Makefile                 |   2 +-
> >  mm/swap.h                   |   3 +-
> >  mm/{page_io.c => swap_io.c} | 104 +++++++++++++++++++++---------------
> >  mm/swapfile.c               |   2 +
> >  mm/zswap.c                  |   3 +-
> >  7 files changed, 80 insertions(+), 49 deletions(-)
> >  rename mm/{page_io.c => swap_io.c} (91%)
> > 
> > -- 
> > 2.52.0
> 
> Hi Baoquan,
> 
> Thank you for the swap_ops infrastructure patch. This is very
> relevant to our flash swap work, and I believe it could
> significantly help with our future contributions if the framework
> is extended further.
> 
> As I understand it, the current patch serves as a foundation for
> future infrastructure. However, from our perspective, the swap ops
> are currently configured statically, and we would need a way to
> apply or register custom ops for our use case.

Thanks a lot for your input about the future potential use cases of
swap_ops, they are very valuable.

Yes, this patchset is posted as a infrastructure of swap_ops and a
thread where we collect any potential extention or use case. The
change is made based on the current kernel.

> 
> I have a few suggestions (mixed with questions) regarding
> extensibility.
> 
> 1) Could the ops be replaced at activation time, similar to how
>    SWP_FS_OPS works — i.e., giving block device drivers an
>    opportunity to override the ops when the swap device is
>    activated?
> 
>    This would allow block devices to handle swap read/write
>    through swap_ops rather than doing it in submit_bio, which
>    feels more generalized and leaves room for future extension.
> 
>    This direction would be the best fit for our use case.
>    However, considering ongoing swap work that may involve
>    managing multiple swap devices, I wonder whether binding ops
>    to a single block device would still be appropriate in that
>    scenario.

I think it's doable and make swap_ops more flexible and versatile to
support different swap back ends.

As for binding ops to a swap devices conflicting with managing multiple
swap devices, I may not get your point very clearly. Could you give a
concrete use case to demonstrate?

> 
> 2) Would it be possible to defer swap device activation via a
>    lazy registration interface, so that the ops can be registered
>    before the device is fully activated?
> 
>    This would open the door for entities other than block
>    devices — such as kernel modules or other forms — to act as
>    swap backends. (Of course, block devices could also benefit
>    from this path.)

Yes, I think it's doable. I will make change and send a draft to you for 
evaluation. By the way, do you have actual use case in which deferring
swap activation is needed for justification?

> 
> 3) Alternatively, are there any plans for a static binding
>    mechanism, or any other extensibility approach you have in
>    mind?
> 
> As an additional thought, if this ops framework could eventually
> be extended to cover cluster allocation as well, it might enable
> a model where base swap functionality is provided by the core,
> while each vendor can freely plug in their own additional use
> cases on top — making the swap device truly extensible.

Yes, this is planned task as I have mentioned in the LSF/MM topic mail.


> 
> Any thoughts on these would be greatly appreciated.
> 
> Best regards,
> Youngjun Park 
>