On Wed, Jul 31, 2024 at 7:28 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote: > > On Tue, Jul 30, 2024 at 9:30 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > > > > > Well, that is the point. zram is a horrible hack that abuses a block > > device to implement a feature missing the VM layer. Right now people > > have a reason for it because zswap requires a "real" backing device > > and that's fine for them and for now. But instead of building VM > > I completely agree with this assessment. > > > infrastructure around these kinds of hacks we need to fix the VM > > infrastructure. Chris Li has been talking about and working towards > > a proper swap abstraction and that needs to happen. > > I'm also working towards something along this line. My design would > add a "virtual" swap ID that will be stored in the page table, and can > refer to either a real, storage-backed swap entry, or a zswap entry. > zswap can then exist without any backing swap device. > > There are several additional benefits of this approach: > > 1. We can optimize swapoff as well - the page table can still refer to > the swap ID, but the ID now points to a physical page frame. swapoff > code just needs to sever the link from the swap ID to the physical > swap entry (which either just requires a swap ID mapping walk, or even > faster if we have a reverse mapping mechanism), and update the link to > the page frame instead. > > 2. We can take this opportunity to clean up the swap count code. > > I'd be happy to collaborate/compare notes :) I appreciate that you have a good plan, and I welcome the improvements in zswap. However, we need to face reality. Having a good plan doesn't mean we should wait for you to proceed. In my experience, I've never heard of anyone using zswap in an embedded system, especially among the billions of Android devices.(Correct me if you know one.) How soon do you expect embedded systems and Android to adopt zswap? In one year, two years, five years, or ten years? Have you asked if Google plans to use zswap in Android? Currently, zswap does not support large folios, which is why Yosry has introduced an API like zswap_never_enabled() to allow others to explore parallel options like mTHP swap. Meanwhile, If zswap encounters large folios, it will trigger a SIGBUS error. I believe you were involved in those discussions: mm: zswap: add zswap_never_enabled() https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2d4d2b1cfb85cc07f6 mm: zswap: handle incorrect attempts to load large folios https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c63f210d4891f5b1 Should everyone around the world hold off on working on mTHP swap until zswap has addressed the issue to support large folios? Not to mention whether people are ready and happy to switch to zswap. I don't see any reason why we should wait and not start implementing something that could benefit billions of devices worldwide. Parallel exploration leads to human progress in different fields. That's why I believe Yosry's patch, which allows others to move forward, is a more considerate approach. Thanks Barry
