On Mon, Mar 4, 2024 at 11:49 PM Chris Li <chrisl@xxxxxxxxxx> wrote: > > I have considered that as well, that is further than writing from one > swap device to another. The current swap device currently can't accept > write on non page aligned offset. If we allow byte aligned write out > size, the whole swap entry offset stuff needs some heavy changes. > > If we write out 4K pages, and the compression ratio is lower than 50%, > it means a combination of two compressed pages can't fit into one > page. Which means some of the page read back will need to overflow > into another page. We kind of need a small file system to keep track > of how the compressed data is stored, because it is not page aligned > size any more. > > We can write out zsmalloc blocks of data as it is, however there is no > guarantee the data in zsmalloc blocks have the same LRU order. > > It makes more sense when writing higher order > 0 swap pages. e.g > writing 64K pages in one buffer, then we can write out compressed data > as page boundary aligned and page sizes, accepting the waste on the > last compressed page, might not fill up the whole page. A swap device not a device, until recently, it was a really bad filesystem with no abstractions between the block device and the filesystem. Zswap and zram are, in some respects, attempts to make specialized filesystems without any of the advantages of using the vfs tooling. What stops us from using an existing compressing filesystem? Crazy talk here. What if we handled swap pages like they were mmap'd to a special swap "file(s)"? > Chris >
