Re: [LSF/MM/BPF TOPIC] Swap Abstraction / Native Zswap

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 02, 2023 at 01:23:14PM -0500, Rik van Riel wrote:
> > How about we just put the indirection layer into the swap device?
> 
> The indirection layer needs to be higher up, in order to allow
> for easy movement of swap entries between different devices.

In my mind this "swap device" has some upper layer parts.
Maybe I should not call it a swap device. Let's say it is a
redirect on the swap_info layer.

> 
> For example, we could initially store something in zswap, and
> then later decide we want to write it out to disk swap.
>

Right. We might even want to move swap from SSD into a slower
spinning disk swap space.
 
> This could also be used to quickly free up swap space at swapin
> time, by freeing the backing storage (eg. in zswap, or when disk
> swap is starting to get full)) when placing an uncompressed copy
> of the data in the swap cache. We could apply per-device policies
> on whether or not to free swap space at swapin time, because the
> tradeoffs are just different between eg disk and zswap.
> 
> Doing that would also allow us to turn swapoff into a simple
> "load everything from this device into the swap cache" operation.
> The pageout code can move that data from the swap cache into
> another swap device, without ever having to look up page tables.

I am with you on that.

> 
> One possible implementation might be to have swap page table entries
> point to a swap address in this indirection layer, and the indirection
> layer can be an xarray containing the actual swap entries specifying
> at which position in which swap device the data can be found.

The questions, do we have this indirection layer apply to all swap
entries?

My small tweak is to limit the indirection layer only to non leaf
swap devices. Then it is actually very close to what I am proposing.
Just your "indirection layer" is my "special swap device".

Again, "special swap device" is a very bad name, let's name it something
more useful.

> That might be a net reduction in the code over what we have today,
> because it gets rid of some ugly corner cases.

Great.

Chris





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux