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

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

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.

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.

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

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.

Any thoughts on these would be greatly appreciated.

Best regards,
Youngjun Park