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

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

 



Chris Li <chrisl@xxxxxxxxxx> 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.

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




[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