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

["Huang, Ying" <ying.huang@intel.com>]

Yosry Ahmed <yosryahmed@google.com> writes:

> On Sun, Mar 26, 2023 at 6:24 PM Huang, Ying <ying.huang@intel.com> wrote:
>>
>> Chris Li <chrisl@kernel.org> writes:
>>
>> > On Fri, Mar 24, 2023 at 12:28:31AM -0700, Yosry Ahmed wrote:
>> >> > In fact, I just suggest to use the minimal design on top of the current
>> >> > implementation as the first step.  Then, you can improve it step by
>> >> > step.
>> >> >
>> >> > The first step could be the minimal effort to implement indirection
>> >> > layer and moving swapped pages between swap implementations.  Based on
>> >> > that, you can build other optimizations, such as pulling swap counting
>> >> > to the swap core.  For each step, we can evaluate the gain and cost with
>> >> > data.
>> >>
>> >> Right, I understand that, but to implement the indirection layer on
>> >> top of the current implementation, then we will need to support using
>> >> zswap without a backing swap device. In order to do this without
>> >
>> > Agree with Ying on the minimal approach here as well.
>> >
>> > There are two ways to approach this.
>> >
>> > 1) Forget zswap, make a minimal implementation to move the page between
>> > two swapfile device. It can be swapfile back to two loop back files.
>> >
>> > Any indirect layer you design will need to convert this usage case
>> > any way.
>> >
>> > 2) Make zswap work without a swapfile.
>> > You can implement the zswap on a fake ghosts swap file.
>> >
>> > If you keep the zswap as frontswap, just make zswap can work without
>> > a real swapfile.
>> >
>> > Make that as your first minimal step. Then it does not need to touch
>> > the swap count changes.
>> >
>> > I view make that step is independent of moving pages between swap device.
>> >
>> > That patch exists and I consider it has value to some users.
>>
>> This sounds like an even smaller approach as the first step.  Further
>> improvement can be built on top of it.
>
> I am not sure how this would be a step towards the abstraction goal we
> have been discussing.
>
> We have been discussing starting out with a minimal indirection layer,
> in the shape of an xarray that maps a swap ID to a swap entry, and
> that can be disabled with a config option.
>
> For such a design to work, we have to implement swap entry management
> & swap counting in zswap, right? Am I missing something?

Chris suggested to avoid to implement the swap entry management & swap
counting in zswap via using a "fake ghost swap file".  Copied his
suggestion as below,

"
>> > 2) Make zswap work without a swapfile.
>> > You can implement the zswap on a fake ghosts swap file.
>> >
>> > If you keep the zswap as frontswap, just make zswap can work without
>> > a real swapfile.
>> >
>> > Make that as your first minimal step. Then it does not need to touch
>> > the swap count changes.
"

Best Regards,
Huang, Ying

>>
>> >> > Anyway, I don't think you can just implement all your final solution in
>> >> > one step.  And, I think the minimal design suggested could be a starting
>> >> > point.
>> >>
>> >> I agree that's a great point, I am just afraid that we will avoid
>> >> implementing that full final solution and instead do a lot of work
>> >> inside zswap to make up for the difference (e.g. swap entry
>> >> management, swap counting). Also, that work in zswap may end up being
>> >> unacceptable due to the maintenance burden and/or complexity.
>> >
>> > If you do either 1) or 2), you can keep these two paths separate.
>> >
>> > Even if you want to move the page between zswap and swapfile.
>> >
>> > Idea 3)
>> > You don't have to change the swap count code, you can do a
>> > minimal change moves the page between zswap and another block
>> > device. That way you can get two differenet swap entry with
>> > existing code.
>> >
>> > Chris
>>