On Tue, Sep 17, 2013 at 02:59:24PM +0800, Bob Liu wrote: > Mel mentioned several problems about zswap/zbud in thread "[PATCH v6 > 0/5] zram/zsmalloc promotion". > > Like "it's clunky as hell and the layering between zswap and zbud is > twisty" and "I think I brought up its stalling behaviour during review > when it was being merged. It would have been preferable if writeback > could be initiated in batches and then waited on at the very least.. > It's worse that it uses _swap_writepage directly instead of going > through a writepage ops. It would have been better if zbud pages > existed on the LRU and written back with an address space ops and > properly handled asynchonous writeback." > > So I think it would be better if we can address those issues at first > and it would be easier to address these issues before adding more new > features. Welcome any ideas. I just had an idea this afternoon to potentially kill both these birds with one stone: Replace the rbtree in zswap with an address_space. Each swap type would have its own page_tree to organize the compressed objects by type and offset (radix tree is more suited for this anyway) and a_ops that could be called by shrink_page_list() (writepage) or the migration code (migratepage). Then zbud pages could be put on the normal LRU list, maybe at the beginning of the inactive LRU so they would live for another cycle through the list, then be reclaimed in the normal way with the mapping->a_ops->writepage() pointing to a zswap_writepage() function that would decompress the pages and call __swap_writepage() on them. This might actually do away with the explicit pool size too as the compressed pool pages wouldn't be outside the control of the MM anymore. I'm just starting to explore this but I think it has promise. Seth -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>