[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55D48C5E.7010004@suse.cz>
Date: Wed, 19 Aug 2015 16:02:06 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Dan Streetman <ddstreet@...e.org>,
Jonathan Corbet <corbet@....net>,
Seth Jennings <sjennings@...iantweb.net>,
Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [PATCH] zswap: update docs for runtime-changeable attributes
On 08/18/2015 09:07 PM, Dan Streetman wrote:
> Change the Documentation/vm/zswap.txt doc to indicate that the "zpool"
> and "compressor" params are now changeable at runtime.
>
> Signed-off-by: Dan Streetman <ddstreet@...e.org>
> ---
> Documentation/vm/zswap.txt | 31 +++++++++++++++++++++++--------
> 1 file changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/vm/zswap.txt b/Documentation/vm/zswap.txt
> index 8458c08..06f7ce2 100644
> --- a/Documentation/vm/zswap.txt
> +++ b/Documentation/vm/zswap.txt
> @@ -32,7 +32,7 @@ can also be enabled and disabled at runtime using the sysfs interface.
> An example command to enable zswap at runtime, assuming sysfs is mounted
> at /sys, is:
>
> -echo 1 > /sys/modules/zswap/parameters/enabled
> +echo 1 > /sys/module/zswap/parameters/enabled
>
> When zswap is disabled at runtime it will stop storing pages that are
> being swapped out. However, it will _not_ immediately write out or fault
> @@ -49,14 +49,27 @@ Zswap receives pages for compression through the Frontswap API and is able to
> evict pages from its own compressed pool on an LRU basis and write them back to
> the backing swap device in the case that the compressed pool is full.
>
> -Zswap makes use of zbud for the managing the compressed memory pool. Each
> -allocation in zbud is not directly accessible by address. Rather, a handle is
> +Zswap makes use of zpool for the managing the compressed memory pool. Each
> +allocation in zpool is not directly accessible by address. Rather, a handle is
> returned by the allocation routine and that handle must be mapped before being
> accessed. The compressed memory pool grows on demand and shrinks as compressed
> -pages are freed. The pool is not preallocated.
> +pages are freed. The pool is not preallocated. By default, a zpool of type
> +zbud is created, but it can be selected at boot time by setting the "zpool"
> +attribute, e.g. zswap.zpool=zbud. It can also be changed at runtime using the
> +sysfs "zpool" attribute, e.g.
> +
> +echo zbud > /sys/module/zswap/parameters/zpool
What exactly happens if zswap is already being used and has allocated pages in
one type of pool, and you're changing it to the other one?
> +
> +The zbud type zpool allocates exactly 1 page to store 2 compressed pages, which
> +means the compression ratio will always be exactly 2:1 (not including half-full
> +zbud pages), and any page that compresses to more than 1/2 page in size will be
> +rejected (and written to the swap disk).
Hm is this correct? I've been going through the zbud code briefly (as of Linus'
tree) and it seems to me that it will accept pages larger than 1/2, but they
will sit in the unbuddied list until a small enough "buddy" comes.
> The zsmalloc type zpool has a more
> +complex compressed page storage method, and it can achieve greater storage
> +densities. However, zsmalloc does not implement compressed page eviction, so
> +once zswap fills it cannot evict the oldest page, it can only reject new pages.
I still wonder why anyone would use zsmalloc with zswap given this limitation.
It seems only fine for zram which has no real swap as fallback. And even zbud
doesn't have any shrinker interface that would react to memory pressure, so
there's a possibility of premature OOM... sigh.
> When a swap page is passed from frontswap to zswap, zswap maintains a mapping
> -of the swap entry, a combination of the swap type and swap offset, to the zbud
> +of the swap entry, a combination of the swap type and swap offset, to the zpool
> handle that references that compressed swap page. This mapping is achieved
> with a red-black tree per swap type. The swap offset is the search key for the
> tree nodes.
> @@ -74,9 +87,11 @@ controlled policy:
> * max_pool_percent - The maximum percentage of memory that the compressed
> pool can occupy.
>
> -Zswap allows the compressor to be selected at kernel boot time by setting the
> -“compressor” attribute. The default compressor is lzo. e.g.
> -zswap.compressor=deflate
> +The default compressor is lzo, but it can be selected at boot time by setting
> +the “compressor” attribute, e.g. zswap.compressor=lzo. It can also be changed
> +at runtime using the sysfs "compressor" attribute, e.g.
> +
> +echo lzo > /sys/module/zswap/parameters/compressor
Again, what happens to pages already compressed? Are they freed? Recompressed?
Does zswap remember it has to decompress them differently than the currently
used compressor?
> A debugfs interface is provided for various statistic about pool size, number
> of pages stored, and various counters for the reasons pages are rejected.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists