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:15:32PM -0500, Johannes Weiner wrote:
> > The common swap device related operation can have some swap related
> > swap_device_ops function call back. e.g. get swap_cout. 
> > That way, obviously there will not be much memory overhead for
> > the devicethat doesn't use zswap. 
> > 
> > The zswap entry can still do something similar to your swap_desc, save
> > some pointer to its nested backing device(normal swap file).
> > That way the swap_desc overhead is purely on the zswap side.
> 
> The problem with that is that zswap needs to be able to write its cold
> entries to flash. If zswap and the backing file don't live in a shared
> swap id space, it means that zswap writeback would have to allocate a
> new device/offset tuple and update all the page table references. It
> would impose the complexity of swapoff on every zswap writeout.
>

When writing back to flash, allocating a new device/offset is unavoidable.
Otherwise it means zswap will reserve/waste a device/offset even when
it is not writing back to the flash device.

Update the page table reference can be avoided. By keeping the zswap entry.
When lookup the original zswap offset, it knows that the data has been write
to a flash device, it keeps a pointer of the flash swap entry, returning that instead.
The mechanism is similar to the swap_desc Yosary description.

Will that address your concern?

Basically the indirection layer is on demand.

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