On (23/02/18 14:38), Yosry Ahmed wrote: [..] > ==================== Idea ==================== > Introduce a data structure, which I currently call a swap_desc, as an > abstraction layer between swapping implementation and the rest of MM > code. Page tables & page caches would store a swap id (encoded as a > swp_entry_t) instead of directly storing the swap entry associated > with the swapfile. This swap id maps to a struct swap_desc, which acts > as our abstraction layer. All MM code not concerned with swapping > details would operate in terms of swap descs. The swap_desc can point > to either a normal swap entry (associated with a swapfile) or a zswap > entry. It can also include all non-backend specific operations, such > as the swapcache (which would be a simple pointer in swap_desc), swap > counting, etc. It creates a clear, nice abstraction layer between MM > code and the actual swapping implementation. > > ==================== Benefits ==================== > This work enables using zswap without a backing swapfile and increases > the swap capacity when zswap is used with a swapfile. It also creates > a separation that allows us to skip code paths that don't make sense > in the zswap path (e.g. readahead). We get to drop zswap's rbtree > which might result in better performance (less lookups, less lock > contention). > > The abstraction layer also opens the door for multiple cleanups (e.g. > removing swapper address spaces, removing swap count continuation > code, etc). Another nice cleanup that this work enables would be > separating the overloaded swp_entry_t into two distinct types: one for > things that are stored in page tables / caches, and for actual swap > entries. In the future, we can potentially further optimize how we use > the bits in the page tables instead of sticking everything into the > current type/offset format. > > Another potential win here can be swapoff, which can be more practical > by directly scanning all swap_desc's instead of going through page > tables and shmem page caches. > > Overall zswap becomes more accessible and available to a wider range > of use cases. I assume this also brings us closer to a proper writeback LRU handling?
