Messages in this thread | | | Subject | Re: [PATCH v2 0/5] mm: migrate zbud pages | From | Krzysztof Kozlowski <> | Date | Tue, 24 Sep 2013 11:20:22 +0200 |
| |
Hi,
On pon, 2013-09-23 at 17:07 -0500, Seth Jennings wrote: > 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.
How exactly the address space can be used here? Do you want to point to zbud pages in address_space.page_tree? If yes then which index should be used?
Best regards, Krzysztof
| |