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

[YoungJun Park <youngjun.park@lge.com>]

On Thu, Mar 05, 2026 at 01:18:27PM +0800, Baoquan He wrote:
> 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 understand. I brought up suggestions 1 and 2 because they are necessary
from the perspective of immediate application. :D

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

To clarify my point about binding ops: I was focusing on the initialization
timing. Taking SWP_FS_OPS as an example, setup_swap_extents calls
swap_activate and finally SWP_FS_OPS is set by filesystem.

Similarly, I am suggesting a mechanism that gives the block device (or
another entity) an opportunity to register its specific swap_ops during the
swapon phase by calling some kind of swap_active callback.
(And it may be not the block device as well?)

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

Regarding the use case for deferred activation: This becomes necessary if
we don't use the activation-time binding mentioned in #1.

If we rely on dynamic registration, there is a time window between swapon
and the actual registration of the ops. During this window, the swap device
should not perform I/O since the ops aren't set yet. A lazy registration or
deferred activation mechanism would handle this safety gap.

> > 
> > 3) Alternatively, are there any plans for a static binding
> >    mechanism, or any other extensibility approach you have in
> >    mind?

> How the swap back end was chosen. We can make it a swap mount option.
> We make the swapfile header look like a file system super block. The
> different swapfile header contains different back end types and
> options.

I found your comment about ops binding on LSF/MM/BPF suggestion. sorry for missing.
Okay, I see. While I personally prefer the direction similar to SWP_FS_OPS infrastructure(or #2), 
the mount option or header approach is also a valid path!

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

It is great to hear that custom cluster allocation is planned. this would allow 
vendors to implement optimizations specific to
their swap I look forward to that and will provide comments if we have
concrete use cases.

Thanks a lot for your work
Youngjun Park