Yosry Ahmed <yosryahmed@xxxxxxxxxx> writes: > On Sun, Mar 26, 2023 at 6:24 PM Huang, Ying <ying.huang@xxxxxxxxx> wrote: >> >> 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. > > 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 >>
