linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Seth Jennings <sjenning@linux.vnet.ibm.com>
To: Bob Liu <bob.liu@oracle.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Mel Gorman <mgorman@suse.de>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Dave Hansen <dave.hansen@intel.com>,
	Minchan Kim <minchan@kernel.org>
Subject: Re: [PATCH v2 0/5] mm: migrate zbud pages
Date: Mon, 23 Sep 2013 17:07:57 -0500	[thread overview]
Message-ID: <20130923220757.GC16191@variantweb.net> (raw)
In-Reply-To: <5237FDCC.5010109@oracle.com>

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

  parent reply	other threads:[~2013-09-23 22:08 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-11  8:58 [PATCH v2 0/5] mm: migrate zbud pages Krzysztof Kozlowski
2013-09-11  8:59 ` [PATCH v2 1/5] zbud: use page ref counter for " Krzysztof Kozlowski
2013-09-11  8:59 ` [PATCH v2 2/5] zbud: make freechunks a block local variable Krzysztof Kozlowski
2013-09-11  8:59 ` [PATCH v2 3/5] mm: use mapcount for identifying zbud pages Krzysztof Kozlowski
2013-09-11  8:59 ` [PATCH v2 4/5] mm: use indirect zbud handle and radix tree Krzysztof Kozlowski
2013-09-11  8:59 ` [PATCH v2 5/5] mm: migrate zbud pages Krzysztof Kozlowski
2013-09-17  6:59 ` [PATCH v2 0/5] " Bob Liu
2013-09-23 17:19   ` Seth Jennings
2013-09-23 22:07   ` Seth Jennings [this message]
2013-09-24  9:20     ` Krzysztof Kozlowski
2013-09-25  4:28       ` Bob Liu
2013-09-25 17:09     ` Tomasz Stanislawski
2013-09-25 21:57       ` Seth Jennings
2013-09-27 10:16         ` Tomasz Stanislawski
2013-09-27 22:00           ` Seth Jennings
2013-09-28  2:43             ` Bob Liu
2013-09-30  8:28             ` Krzysztof Kozlowski
2013-10-01 21:04               ` Seth Jennings
2013-10-03 13:24                 ` Krzysztof Kozlowski
2013-10-03 15:39                   ` Seth Jennings

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130923220757.GC16191@variantweb.net \
    --to=sjenning@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=b.zolnierkie@samsung.com \
    --cc=bob.liu@oracle.com \
    --cc=dave.hansen@intel.com \
    --cc=k.kozlowski@samsung.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mgorman@suse.de \
    --cc=minchan@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).