On wto, 2013-10-01 at 16:04 -0500, Seth Jennings wrote: > Yes, it is very similar. I'm beginning to like aspects of this patch > more as I explore this issue more. > > At first, I balked at the idea of yet another abstraction layer, but it > is very hard to avoid unless you want to completely collapse zswap and > zbud into one another and dissolve the layering. Then you could do a > direct swap_offset -> address mapping. After discussion with Tomasz Stanislawski we had an idea of merging the trees (zswap's rb and zbud's radix added in these patches) into one tree in zbud layer. This would simplify the design (if migration was added, of course). The idea looks like: 1. Get rid of the red-black tree in zswap. 2. Add radix tree to zbud (or use radix tree from address space). - Use offset (from swp_entry) as index to radix tree. - zbud page (struct page) stored in tree. 4. With both buddies filled one zbud page would be put in radix tree twice. 5. zbud API would look like: zbud_alloc(struct zbud_pool *pool, int size, gfp_t gfp, pgoff_t offset) zbud_free(struct zbud_pool *pool, pgoff_t offset) zbud_map(struct zbud_pool *pool, pgoff_t offset) etc. 6. zbud_map/unmap() would be a little more complex than now as it would took over some code from zswap (finding offset in tree). 7. The radix tree would be used for: - finding entry by offset (for zswap_frontswap_load() and others), - migration. 8. In case of migration colliding with zbud_map/unmap() the locking could be limited (in comparison to my patch). Calling zbud_map() would mark a page "dirty". During migration if page was "dirtied" then migration would fail with EAGAIN. Of course migration won't start if zbud buddy was mapped. What do you think about this? Best regards, Krzysztof -- 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>