Re: [PATCH v2 0/5] mm: migrate zbud pages

[Seth Jennings <sjenning@linux.vnet.ibm.com>]

On Thu, Oct 03, 2013 at 03:24:20PM +0200, Krzysztof Kozlowski wrote:
> 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.

I have also been converging on this idea.  It took me a while because I
just wouldn't entertain the idea of there being no translation at the
zswap layer.  But I'm starting to think this is the best way.

It does create more work for any new allocator as a lot of the
complexity has been shifted to that layer.  However, it is the only
layer that it makes since to do this management (reclaim/migration).

> 
> 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?

I like it.  We just need to keep reclaim in mind as well as migration.
i.e. need to design with the knowledge that zbud pages will be on the
LRU lists.

Thanks for thinking about this!

Seth

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>