[LSF/MM/BPF TOPIC] swap_ops and plugable swap back end

[Baoquan He <bhe@redhat.com>]

The swap_ops provides an unified interface to allow registering
different swap back ends to coexist in the kernel with their private
implementations of how the swap behavior was handled. e.g. the "flash
friendly swap layout" proposed by Yongjun in another LSF/MM topic,
which is more about flash related swap. I want to dedicate this
discussion topic to the infrastructure to support that: the swap_ops.
Another potential user is Android, Android team has been wanting
to swap out compressed data to reduce the amount of the IO needed to
perform on the swap backend.

The plugable swap backend is somewhat similar to the file system.  I
hesitate to call it a swap file system because it is not a file system
in the traditional sense. The API is tailored to the swap specific
usage. Even though the swap entry looks like an inode, it does not have
the concept of directory and does not use the VFS data structures. It
uses swap tables to keep track of the frontend related swap metadata.
(e.g. swap count). The back end can choose where the data is actually
stored and how it is stored.

The typical operation includes: read/write a swap page, allocate a
swap entry and maybe more.

The current core swap already has synchronous block device vs
asynchronous block device. Those can be moved into two different
plugable swap back ends. These swap_ops expect to have no additional
cost to the existing swap behavior other than calling through the
swap_ops function callback pointer.

Discussion:

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.

How to handle storing compressed data. e.g. data from zram directly
write to the swap backend without uncompressing.

How to allocate swap backend's private swap entry meta data with
minimal memory overhead.