This is the latest version of the zswap patchset for compressed swap caching.
This is submitted for merging into linux-next and inclusion in v3.11.
New in this Version:
Lucky 13!
Integrated feedback from Andrew and moved zbud page metadata out of the
struct page to an in-line header structure.
Useful References:
LSFMM: In-kernel memory compression
https://lwn.net/Articles/548109/
The zswap compressed swap cache
https://lwn.net/Articles/537422/
Zswap Overview:
Zswap is a lightweight compressed cache for swap pages. It takes
pages that are in the process of being swapped out and attempts to
compress them into a dynamically allocated RAM-based memory pool.
If this process is successful, the writeback to the swap device is
deferred and, in many cases, avoided completely. This results in
a significant I/O reduction and performance gains for systems that
are swapping.
The results of a kernel building benchmark indicate a
runtime reduction of 53% and an I/O reduction 76% with zswap vs normal
swapping with a kernel build under heavy memory pressure (see
Performance section for more).
Some addition performance metrics regarding the performance
improvements and I/O reductions that can be achieved using zswap as
measured by SPECjbb are provided here:
http://ibm.co/VCgHvM
These results include runs on x86 and new results on Power7+ with
hardware compression acceleration.
Of particular note is that zswap is able to evict pages from the compressed
cache, on an LRU basis, to the backing swap device when the compressed pool
reaches it size limit or the pool is unable to obtain additional pages
from the buddy allocator. This eviction functionality had been identified
as a requirement in prior community discussions.
Rationale:
Zswap provides compressed swap caching that basically trades CPU cycles
for reduced swap I/O. This trade-off can result in a significant
performance improvement as reads to/writes from to the compressed
cache almost always faster that reading from a swap device
which incurs the latency of an asynchronous block I/O read.
Some potential benefits:
* Desktop/laptop users with limited RAM capacities can mitigate the
performance impact of swapping.
* Overcommitted guests that share a common I/O resource can
dramatically reduce their swap I/O pressure, avoiding heavy
handed I/O throttling by the hypervisor. This allows more work
to get done with less impact to the guest workload and guests
sharing the I/O subsystem
* Users with SSDs as swap devices can extend the life of the device by
drastically reducing life-shortening writes.
Compressed swap is also provided in zcache, along with page cache
compression and RAM clustering through RAMSter. Zswap seeks to deliver
the benefit of swap compression to users in a discrete function.
This design decision is akin to Unix design philosophy of doing one
thing well, it leaves file cache compression and other features
for separate code.
Design:
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 or unable to secure additional pages from
the buddy allocator.
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 return 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.
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 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.
Zswap seeks to be simple in its policies. Sysfs attributes allow for
two user controlled policies:
* max_compression_ratio - Maximum compression ratio, as as percentage,
for an acceptable compressed page. Any page that does not compress
by at least this ratio will be rejected.
* max_pool_percent - The maximum percentage of memory that the compressed
pool can occupy.
To enabled zswap, the "enabled" attribute must be set to 1 at boot time.
Zswap allows the compressor to be selected at kernel boot time by
setting the “compressor” attribute. The default compressor is lzo.
A debugfs interface is provided for various statistic about pool size,
number of pages stored, and various counters for the reasons pages
are rejected.
Changelog:
v13:
* integrated feedback from Andrew
* moved zbud pool page metadata from struct page to in-line header
contained in the page itself, avoiding potential issues with
(broken?) code that accesses struct pages directly from the memmap
array.
v12:
* updated Kconfig help and Documentation to indicate zswap is experimental
* remove max_compression_ratio tunable
* make zbud_pool's pages_nr lock protected and non-atomic
* don't export zbud symbols
* refactor reset_zbud_page()/__free_page() into free_zbud_page()
* make zsawp_pool_pages non-atomic
* zswap_enabled add __read_mostly
* remove type field from zswap_tree
* various comment changes
v11:
* fixup symbol collision with lib/fault-inject.c (Greg)
* rebase v3.10-rc1
v10:
* replace zsmalloc with zbud (zsmalloc to come back as option in future dev)
* lru logic moved out of zswap into allocator
* simplified and improved writeback logic
* removed memory pool and tmpage pool as part of refactoring
* Rebase to (almost) v3.10-rc1
v9:
* Fix load-during-writeback race; double lru add (for real this time)
* checkpatch and comment fixes
* Fix __swap_writepage() return value check
* Move check for max outstanding writebacks (dedup some code)
* Rebase to v3.9-rc6
v8:
* Fix load-during-writeback race; double lru add
* checkpatch fixups
* s/NOWAIT/ATOMIC for tree allocation (Dave)
* Check __swap_writepage() for error before incr outstanding write count (Rob)
* Convert pcpu compression buffer alloc from alloc_page() to kmalloc() (Dave)
* Rebase to v3.9-rc5
v7:
* Decrease zswap_stored_pages during tree cleanup (Joonsoo)
* Move zswap_entry_cache_alloc() earlier during store (Joonsoo)
* Move type field from struct zswap_entry to struct zswap_tree
* Change to swapper_space array (-rc1 change)
* s/reset_page_mapcount/page_mapcount_reset in zsmalloc (-rc1 change)
* Rebase to v3.9-rc1
v6:
* fix access-after-free regression introduced in v5
(rb_erase() outside the lock)
* fix improper freeing of rbtree (Cody)
* fix comment typo (Ric)
* add comments about ZS_MM_WO usage and page mapping mode (Joonsoo)
* don't use page->object (Joonsoo)
* remove DEBUG (Joonsoo)
* rebase to v3.8
v5:
* zsmalloc patch converted from promotion to "new code" (for review only,
see note in [1/8])
* promote zsmalloc to mm/ instead of /lib
* add more documentation everywhere
* convert USE_PGTABLE_MAPPING to kconfig option, thanks to Minchan
* s/flush/writeback/
* #define pr_fmt() for formatting messages (Joe)
* checkpatch fixups
* lots of changes suggested Minchan
v4:
* Added Acks (Minchan)
* Separated flushing functionality into standalone patch
for easier review (Minchan)
* fix comment on zswap enabled attribute (Minchan)
* add TODO for dynamic mempool size (Minchan)
* and check for NULL in zswap_free_page() (Minchan)
* add missing zs_free() in error path (Minchan)
* TODO: add comments for flushing/refcounting (Minchan)
v3:
* Dropped the zsmalloc patches from the set, except the promotion patch
which has be converted to a rename patch (vs full diff). The dropped
patches have been Acked and are going into Greg's staging tree soon.
* Separated [PATCHv2 7/9] into two patches since it makes changes for two
different reasons (Minchan)
* Moved ZSWAP_MAX_OUTSTANDING_FLUSHES near the top in zswap.c (Rik)
* Rebase to v3.8-rc5. linux-next is a little volatile with the
swapper_space per type changes which will effect this patchset.
* TODO: Move some stats from debugfs to sysfs. Which ones? (Rik)
v2:
* Rename zswap_fs_* functions to zswap_frontswap_* to avoid
confusion with "filesystem"
* Add comment about what the tree lock protects
* Remove "#if 0" code (should have been done before)
* Break out changes to existing swap code into separate patch
* Fix blank line EOF warning on documentation file
* Rebase to next-20130107
Performance, Kernel Building:
Setup
========
Gentoo w/ kernel v3.7-rc7
Quad-core i5-2500 @ 3.3GHz
512MB DDR3 1600MHz (limited with mem=512m on boot)
Filesystem and swap on 80GB HDD (about 58MB/s with hdparm -t)
majflt are major page faults reported by the time command
pswpin/out is the delta of pswpin/out from /proc/vmstat before and after
the make -jN
Summary
========
* Zswap reduces I/O and improves performance at all swap pressure levels.
* Under heavy swaping at 24 threads, zswap reduced I/O by 76%, saving
over 1.5GB of I/O, and cut runtime in half.
Details
========
I/O (in pages)
base zswap change change
N pswpin pswpout majflt I/O sum pswpin pswpout majflt I/O sum %I/O MB
8 1 335 291 627 0 0 249 249 -60% 1
12 3688 14315 5290 23293 123 860 5954 6937 -70% 64
16 12711 46179 16803 75693 2936 7390 46092 56418 -25% 75
20 42178 133781 49898 225857 9460 28382 92951 130793 -42% 371
24 96079 357280 105242 558601 7719 18484 109309 135512 -76% 1653
Runtime (in seconds)
N base zswap %change
8 107 107 0%
12 128 110 -14%
16 191 179 -6%
20 371 240 -35%
24 570 267 -53%
%CPU utilization (out of 400% on 4 cpus)
N base zswap %change
8 317 319 1%
12 267 311 16%
16 179 191 7%
20 94 143 52%
24 60 128 113%
Seth Jennings (4):
debugfs: add get/set for atomic types
zbud: add to mm/
zswap: add to mm/
zswap: add documentation
Documentation/vm/zswap.txt | 68 ++++
fs/debugfs/file.c | 42 ++
include/linux/debugfs.h | 2 +
include/linux/zbud.h | 22 ++
lib/fault-inject.c | 21 -
mm/Kconfig | 30 ++
mm/Makefile | 2 +
mm/zbud.c | 526 ++++++++++++++++++++++++
mm/zswap.c | 943 ++++++++++++++++++++++++++++++++++++++++++++
9 files changed, 1635 insertions(+), 21 deletions(-)
create mode 100644 Documentation/vm/zswap.txt
create mode 100644 include/linux/zbud.h
create mode 100644 mm/zbud.c
create mode 100644 mm/zswap.c
--
1.7.9.5
debugfs currently lack the ability to create attributes
that set/get atomic_t values.
This patch adds support for this through a new
debugfs_create_atomic_t() function.
Signed-off-by: Seth Jennings <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Mel Gorman <[email protected]>
Acked-by: Rik van Riel <[email protected]>
---
fs/debugfs/file.c | 42 ++++++++++++++++++++++++++++++++++++++++++
include/linux/debugfs.h | 2 ++
lib/fault-inject.c | 21 ---------------------
3 files changed, 44 insertions(+), 21 deletions(-)
diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index c5ca6ae..ff64bcd 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -21,6 +21,7 @@
#include <linux/debugfs.h>
#include <linux/io.h>
#include <linux/slab.h>
+#include <linux/atomic.h>
static ssize_t default_read_file(struct file *file, char __user *buf,
size_t count, loff_t *ppos)
@@ -403,6 +404,47 @@ struct dentry *debugfs_create_size_t(const char *name, umode_t mode,
}
EXPORT_SYMBOL_GPL(debugfs_create_size_t);
+static int debugfs_atomic_t_set(void *data, u64 val)
+{
+ atomic_set((atomic_t *)data, val);
+ return 0;
+}
+static int debugfs_atomic_t_get(void *data, u64 *val)
+{
+ *val = atomic_read((atomic_t *)data);
+ return 0;
+}
+DEFINE_SIMPLE_ATTRIBUTE(fops_atomic_t, debugfs_atomic_t_get,
+ debugfs_atomic_t_set, "%lld\n");
+DEFINE_SIMPLE_ATTRIBUTE(fops_atomic_t_ro, debugfs_atomic_t_get, NULL, "%lld\n");
+DEFINE_SIMPLE_ATTRIBUTE(fops_atomic_t_wo, NULL, debugfs_atomic_t_set, "%lld\n");
+
+/**
+ * debugfs_create_atomic_t - create a debugfs file that is used to read and
+ * write an atomic_t value
+ * @name: a pointer to a string containing the name of the file to create.
+ * @mode: the permission that the file should have
+ * @parent: a pointer to the parent dentry for this file. This should be a
+ * directory dentry if set. If this parameter is %NULL, then the
+ * file will be created in the root of the debugfs filesystem.
+ * @value: a pointer to the variable that the file should read to and write
+ * from.
+ */
+struct dentry *debugfs_create_atomic_t(const char *name, umode_t mode,
+ struct dentry *parent, atomic_t *value)
+{
+ /* if there are no write bits set, make read only */
+ if (!(mode & S_IWUGO))
+ return debugfs_create_file(name, mode, parent, value,
+ &fops_atomic_t_ro);
+ /* if there are no read bits set, make write only */
+ if (!(mode & S_IRUGO))
+ return debugfs_create_file(name, mode, parent, value,
+ &fops_atomic_t_wo);
+
+ return debugfs_create_file(name, mode, parent, value, &fops_atomic_t);
+}
+EXPORT_SYMBOL_GPL(debugfs_create_atomic_t);
static ssize_t read_file_bool(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
index 63f2465..d68b4ea 100644
--- a/include/linux/debugfs.h
+++ b/include/linux/debugfs.h
@@ -79,6 +79,8 @@ struct dentry *debugfs_create_x64(const char *name, umode_t mode,
struct dentry *parent, u64 *value);
struct dentry *debugfs_create_size_t(const char *name, umode_t mode,
struct dentry *parent, size_t *value);
+struct dentry *debugfs_create_atomic_t(const char *name, umode_t mode,
+ struct dentry *parent, atomic_t *value);
struct dentry *debugfs_create_bool(const char *name, umode_t mode,
struct dentry *parent, u32 *value);
diff --git a/lib/fault-inject.c b/lib/fault-inject.c
index c5c7a76..d7d501e 100644
--- a/lib/fault-inject.c
+++ b/lib/fault-inject.c
@@ -182,27 +182,6 @@ static struct dentry *debugfs_create_stacktrace_depth(
#endif /* CONFIG_FAULT_INJECTION_STACKTRACE_FILTER */
-static int debugfs_atomic_t_set(void *data, u64 val)
-{
- atomic_set((atomic_t *)data, val);
- return 0;
-}
-
-static int debugfs_atomic_t_get(void *data, u64 *val)
-{
- *val = atomic_read((atomic_t *)data);
- return 0;
-}
-
-DEFINE_SIMPLE_ATTRIBUTE(fops_atomic_t, debugfs_atomic_t_get,
- debugfs_atomic_t_set, "%lld\n");
-
-static struct dentry *debugfs_create_atomic_t(const char *name, umode_t mode,
- struct dentry *parent, atomic_t *value)
-{
- return debugfs_create_file(name, mode, parent, value, &fops_atomic_t);
-}
-
struct dentry *fault_create_debugfs_attr(const char *name,
struct dentry *parent, struct fault_attr *attr)
{
--
1.7.9.5
zswap is a thin backend for frontswap that takes pages that are in the process
of being swapped out and attempts to compress them and store them in a
RAM-based memory pool. This can result in a significant I/O reduction on the
swap device and, in the case where decompressing from RAM is faster than
reading from the swap device, can also improve workload performance.
It also has support for evicting swap pages that are currently compressed in
zswap to the swap device on an LRU(ish) basis. This functionality makes zswap a
true cache in that, once the cache is full, the oldest pages can be moved out
of zswap to the swap device so newer pages can be compressed and stored in
zswap.
This patch adds the zswap driver to mm/
Signed-off-by: Seth Jennings <[email protected]>
Acked-by: Rik van Riel <[email protected]>
---
mm/Kconfig | 20 ++
mm/Makefile | 1 +
mm/zswap.c | 943 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 964 insertions(+)
create mode 100644 mm/zswap.c
diff --git a/mm/Kconfig b/mm/Kconfig
index 3367ac3..eec97f2 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -487,3 +487,23 @@ config ZBUD
page. While this design limits storage density, it has simple and
deterministic reclaim properties that make it preferable to a higher
density approach when reclaim will be used.
+
+config ZSWAP
+ bool "Compressed cache for swap pages (EXPERIMENTAL)"
+ depends on FRONTSWAP && CRYPTO
+ select CRYPTO_LZO
+ select ZBUD
+ default n
+ help
+ A lightweight compressed cache for swap pages. It takes
+ pages that are in the process of being swapped out and attempts to
+ compress them into a dynamically allocated RAM-based memory pool.
+ This can result in a significant I/O reduction on swap device and,
+ in the case where decompressing from RAM is faster that swap device
+ reads, can also improve workload performance.
+
+ This is marked experimental because it is a new feature (as of
+ v3.11) that interacts heavily with memory reclaim. While these
+ interactions don't cause any known issues on simple memory setups,
+ they have not be fully explored on the large set of potential
+ configurations and workloads that exist.
diff --git a/mm/Makefile b/mm/Makefile
index 95f0197..f008033 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_HAVE_MEMBLOCK) += memblock.o
obj-$(CONFIG_BOUNCE) += bounce.o
obj-$(CONFIG_SWAP) += page_io.o swap_state.o swapfile.o
obj-$(CONFIG_FRONTSWAP) += frontswap.o
+obj-$(CONFIG_ZSWAP) += zswap.o
obj-$(CONFIG_HAS_DMA) += dmapool.o
obj-$(CONFIG_HUGETLBFS) += hugetlb.o
obj-$(CONFIG_NUMA) += mempolicy.o
diff --git a/mm/zswap.c b/mm/zswap.c
new file mode 100644
index 0000000..deda2b6
--- /dev/null
+++ b/mm/zswap.c
@@ -0,0 +1,943 @@
+/*
+ * zswap.c - zswap driver file
+ *
+ * zswap is a backend for frontswap that takes pages that are in the process
+ * of being swapped out and attempts to compress and store them in a
+ * RAM-based memory pool. This can result in a significant I/O reduction on
+ * the swap device and, in the case where decompressing from RAM is faster
+ * than reading from the swap device, can also improve workload performance.
+ *
+ * Copyright (C) 2012 Seth Jennings <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+*/
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/module.h>
+#include <linux/cpu.h>
+#include <linux/highmem.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+#include <linux/atomic.h>
+#include <linux/frontswap.h>
+#include <linux/rbtree.h>
+#include <linux/swap.h>
+#include <linux/crypto.h>
+#include <linux/mempool.h>
+#include <linux/zbud.h>
+
+#include <linux/mm_types.h>
+#include <linux/page-flags.h>
+#include <linux/swapops.h>
+#include <linux/writeback.h>
+#include <linux/pagemap.h>
+
+/*********************************
+* statistics
+**********************************/
+/* Number of memory pages used by the compressed pool */
+static u64 zswap_pool_pages;
+/* The number of compressed pages currently stored in zswap */
+static atomic_t zswap_stored_pages = ATOMIC_INIT(0);
+
+/*
+ * The statistics below are not protected from concurrent access for
+ * performance reasons so they may not be a 100% accurate. However,
+ * they do provide useful information on roughly how many times a
+ * certain event is occurring.
+*/
+
+/* Pool limit was hit (see zswap_max_pool_percent) */
+static u64 zswap_pool_limit_hit;
+/* Pages written back when pool limit was reached */
+static u64 zswap_written_back_pages;
+/* Store failed due to a reclaim failure after pool limit was reached */
+static u64 zswap_reject_reclaim_fail;
+/* Compressed page was too big for the allocator to (optimally) store */
+static u64 zswap_reject_compress_poor;
+/* Store failed because underlying allocator could not get memory */
+static u64 zswap_reject_alloc_fail;
+/* Store failed because the entry metadata could not be allocated (rare) */
+static u64 zswap_reject_kmemcache_fail;
+/* Duplicate store was encountered (rare) */
+static u64 zswap_duplicate_entry;
+
+/*********************************
+* tunables
+**********************************/
+/* Enable/disable zswap (disabled by default, fixed at boot for now) */
+static bool zswap_enabled __read_mostly;
+module_param_named(enabled, zswap_enabled, bool, 0);
+
+/* Compressor to be used by zswap (fixed at boot for now) */
+#define ZSWAP_COMPRESSOR_DEFAULT "lzo"
+static char *zswap_compressor = ZSWAP_COMPRESSOR_DEFAULT;
+module_param_named(compressor, zswap_compressor, charp, 0);
+
+/* The maximum percentage of memory that the compressed pool can occupy */
+static unsigned int zswap_max_pool_percent = 20;
+module_param_named(max_pool_percent,
+ zswap_max_pool_percent, uint, 0644);
+
+/*********************************
+* compression functions
+**********************************/
+/* per-cpu compression transforms */
+static struct crypto_comp * __percpu *zswap_comp_pcpu_tfms;
+
+enum comp_op {
+ ZSWAP_COMPOP_COMPRESS,
+ ZSWAP_COMPOP_DECOMPRESS
+};
+
+static int zswap_comp_op(enum comp_op op, const u8 *src, unsigned int slen,
+ u8 *dst, unsigned int *dlen)
+{
+ struct crypto_comp *tfm;
+ int ret;
+
+ tfm = *per_cpu_ptr(zswap_comp_pcpu_tfms, get_cpu());
+ switch (op) {
+ case ZSWAP_COMPOP_COMPRESS:
+ ret = crypto_comp_compress(tfm, src, slen, dst, dlen);
+ break;
+ case ZSWAP_COMPOP_DECOMPRESS:
+ ret = crypto_comp_decompress(tfm, src, slen, dst, dlen);
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ put_cpu();
+ return ret;
+}
+
+static int __init zswap_comp_init(void)
+{
+ if (!crypto_has_comp(zswap_compressor, 0, 0)) {
+ pr_info("%s compressor not available\n", zswap_compressor);
+ /* fall back to default compressor */
+ zswap_compressor = ZSWAP_COMPRESSOR_DEFAULT;
+ if (!crypto_has_comp(zswap_compressor, 0, 0))
+ /* can't even load the default compressor */
+ return -ENODEV;
+ }
+ pr_info("using %s compressor\n", zswap_compressor);
+
+ /* alloc percpu transforms */
+ zswap_comp_pcpu_tfms = alloc_percpu(struct crypto_comp *);
+ if (!zswap_comp_pcpu_tfms)
+ return -ENOMEM;
+ return 0;
+}
+
+static void zswap_comp_exit(void)
+{
+ /* free percpu transforms */
+ if (zswap_comp_pcpu_tfms)
+ free_percpu(zswap_comp_pcpu_tfms);
+}
+
+/*********************************
+* data structures
+**********************************/
+/*
+ * struct zswap_entry
+ *
+ * This structure contains the metadata for tracking a single compressed
+ * page within zswap.
+ *
+ * rbnode - links the entry into red-black tree for the appropriate swap type
+ * refcount - the number of outstanding reference to the entry. This is needed
+ * to protect against premature freeing of the entry by code
+ * concurent calls to load, invalidate, and writeback. The lock
+ * for the zswap_tree structure that contains the entry must
+ * be held while changing the refcount. Since the lock must
+ * be held, there is no reason to also make refcount atomic.
+ * offset - the swap offset for the entry. Index into the red-black tree.
+ * handle - zsmalloc allocation handle that stores the compressed page data
+ * length - the length in bytes of the compressed page data. Needed during
+ * decompression
+ */
+struct zswap_entry {
+ struct rb_node rbnode;
+ pgoff_t offset;
+ int refcount;
+ unsigned int length;
+ unsigned long handle;
+};
+
+struct zswap_header {
+ swp_entry_t swpentry;
+};
+
+/*
+ * The tree lock in the zswap_tree struct protects a few things:
+ * - the rbtree
+ * - the refcount field of each entry in the tree
+ */
+struct zswap_tree {
+ struct rb_root rbroot;
+ spinlock_t lock;
+ struct zbud_pool *pool;
+};
+
+static struct zswap_tree *zswap_trees[MAX_SWAPFILES];
+
+/*********************************
+* zswap entry functions
+**********************************/
+static struct kmem_cache *zswap_entry_cache;
+
+static int zswap_entry_cache_create(void)
+{
+ zswap_entry_cache = KMEM_CACHE(zswap_entry, 0);
+ return (zswap_entry_cache == NULL);
+}
+
+static void zswap_entry_cache_destory(void)
+{
+ kmem_cache_destroy(zswap_entry_cache);
+}
+
+static struct zswap_entry *zswap_entry_cache_alloc(gfp_t gfp)
+{
+ struct zswap_entry *entry;
+ entry = kmem_cache_alloc(zswap_entry_cache, gfp);
+ if (!entry)
+ return NULL;
+ entry->refcount = 1;
+ return entry;
+}
+
+static void zswap_entry_cache_free(struct zswap_entry *entry)
+{
+ kmem_cache_free(zswap_entry_cache, entry);
+}
+
+/* caller must hold the tree lock */
+static void zswap_entry_get(struct zswap_entry *entry)
+{
+ entry->refcount++;
+}
+
+/* caller must hold the tree lock */
+static int zswap_entry_put(struct zswap_entry *entry)
+{
+ entry->refcount--;
+ return entry->refcount;
+}
+
+/*********************************
+* rbtree functions
+**********************************/
+static struct zswap_entry *zswap_rb_search(struct rb_root *root, pgoff_t offset)
+{
+ struct rb_node *node = root->rb_node;
+ struct zswap_entry *entry;
+
+ while (node) {
+ entry = rb_entry(node, struct zswap_entry, rbnode);
+ if (entry->offset > offset)
+ node = node->rb_left;
+ else if (entry->offset < offset)
+ node = node->rb_right;
+ else
+ return entry;
+ }
+ return NULL;
+}
+
+/*
+ * In the case that a entry with the same offset is found, a pointer to
+ * the existing entry is stored in dupentry and the function returns -EEXIST
+ */
+static int zswap_rb_insert(struct rb_root *root, struct zswap_entry *entry,
+ struct zswap_entry **dupentry)
+{
+ struct rb_node **link = &root->rb_node, *parent = NULL;
+ struct zswap_entry *myentry;
+
+ while (*link) {
+ parent = *link;
+ myentry = rb_entry(parent, struct zswap_entry, rbnode);
+ if (myentry->offset > entry->offset)
+ link = &(*link)->rb_left;
+ else if (myentry->offset < entry->offset)
+ link = &(*link)->rb_right;
+ else {
+ *dupentry = myentry;
+ return -EEXIST;
+ }
+ }
+ rb_link_node(&entry->rbnode, parent, link);
+ rb_insert_color(&entry->rbnode, root);
+ return 0;
+}
+
+/*********************************
+* per-cpu code
+**********************************/
+static DEFINE_PER_CPU(u8 *, zswap_dstmem);
+
+static int __zswap_cpu_notifier(unsigned long action, unsigned long cpu)
+{
+ struct crypto_comp *tfm;
+ u8 *dst;
+
+ switch (action) {
+ case CPU_UP_PREPARE:
+ tfm = crypto_alloc_comp(zswap_compressor, 0, 0);
+ if (IS_ERR(tfm)) {
+ pr_err("can't allocate compressor transform\n");
+ return NOTIFY_BAD;
+ }
+ *per_cpu_ptr(zswap_comp_pcpu_tfms, cpu) = tfm;
+ dst = kmalloc(PAGE_SIZE * 2, GFP_KERNEL);
+ if (!dst) {
+ pr_err("can't allocate compressor buffer\n");
+ crypto_free_comp(tfm);
+ *per_cpu_ptr(zswap_comp_pcpu_tfms, cpu) = NULL;
+ return NOTIFY_BAD;
+ }
+ per_cpu(zswap_dstmem, cpu) = dst;
+ break;
+ case CPU_DEAD:
+ case CPU_UP_CANCELED:
+ tfm = *per_cpu_ptr(zswap_comp_pcpu_tfms, cpu);
+ if (tfm) {
+ crypto_free_comp(tfm);
+ *per_cpu_ptr(zswap_comp_pcpu_tfms, cpu) = NULL;
+ }
+ dst = per_cpu(zswap_dstmem, cpu);
+ kfree(dst);
+ per_cpu(zswap_dstmem, cpu) = NULL;
+ break;
+ default:
+ break;
+ }
+ return NOTIFY_OK;
+}
+
+static int zswap_cpu_notifier(struct notifier_block *nb,
+ unsigned long action, void *pcpu)
+{
+ unsigned long cpu = (unsigned long)pcpu;
+ return __zswap_cpu_notifier(action, cpu);
+}
+
+static struct notifier_block zswap_cpu_notifier_block = {
+ .notifier_call = zswap_cpu_notifier
+};
+
+static int zswap_cpu_init(void)
+{
+ unsigned long cpu;
+
+ get_online_cpus();
+ for_each_online_cpu(cpu)
+ if (__zswap_cpu_notifier(CPU_UP_PREPARE, cpu) != NOTIFY_OK)
+ goto cleanup;
+ register_cpu_notifier(&zswap_cpu_notifier_block);
+ put_online_cpus();
+ return 0;
+
+cleanup:
+ for_each_online_cpu(cpu)
+ __zswap_cpu_notifier(CPU_UP_CANCELED, cpu);
+ put_online_cpus();
+ return -ENOMEM;
+}
+
+/*********************************
+* helpers
+**********************************/
+static bool zswap_is_full(void)
+{
+ return (totalram_pages * zswap_max_pool_percent / 100 <
+ zswap_pool_pages);
+}
+
+/*
+ * Carries out the common pattern of freeing and entry's zsmalloc allocation,
+ * freeing the entry itself, and decrementing the number of stored pages.
+ */
+static void zswap_free_entry(struct zswap_tree *tree, struct zswap_entry *entry)
+{
+ zbud_free(tree->pool, entry->handle);
+ zswap_entry_cache_free(entry);
+ atomic_dec(&zswap_stored_pages);
+ zswap_pool_pages = zbud_get_pool_size(tree->pool);
+}
+
+/*********************************
+* writeback code
+**********************************/
+/* return enum for zswap_get_swap_cache_page */
+enum zswap_get_swap_ret {
+ ZSWAP_SWAPCACHE_NEW,
+ ZSWAP_SWAPCACHE_EXIST,
+ ZSWAP_SWAPCACHE_NOMEM
+};
+
+/*
+ * zswap_get_swap_cache_page
+ *
+ * This is an adaption of read_swap_cache_async()
+ *
+ * This function tries to find a page with the given swap entry
+ * in the swapper_space address space (the swap cache). If the page
+ * is found, it is returned in retpage. Otherwise, a page is allocated,
+ * added to the swap cache, and returned in retpage.
+ *
+ * If success, the swap cache page is returned in retpage
+ * Returns 0 if page was already in the swap cache, page is not locked
+ * Returns 1 if the new page needs to be populated, page is locked
+ * Returns <0 on error
+ */
+static int zswap_get_swap_cache_page(swp_entry_t entry,
+ struct page **retpage)
+{
+ struct page *found_page, *new_page = NULL;
+ struct address_space *swapper_space = &swapper_spaces[swp_type(entry)];
+ int err;
+
+ *retpage = NULL;
+ do {
+ /*
+ * First check the swap cache. Since this is normally
+ * called after lookup_swap_cache() failed, re-calling
+ * that would confuse statistics.
+ */
+ found_page = find_get_page(swapper_space, entry.val);
+ if (found_page)
+ break;
+
+ /*
+ * Get a new page to read into from swap.
+ */
+ if (!new_page) {
+ new_page = alloc_page(GFP_KERNEL);
+ if (!new_page)
+ break; /* Out of memory */
+ }
+
+ /*
+ * call radix_tree_preload() while we can wait.
+ */
+ err = radix_tree_preload(GFP_KERNEL);
+ if (err)
+ break;
+
+ /*
+ * Swap entry may have been freed since our caller observed it.
+ */
+ err = swapcache_prepare(entry);
+ if (err == -EEXIST) { /* seems racy */
+ radix_tree_preload_end();
+ continue;
+ }
+ if (err) { /* swp entry is obsolete ? */
+ radix_tree_preload_end();
+ break;
+ }
+
+ /* May fail (-ENOMEM) if radix-tree node allocation failed. */
+ __set_page_locked(new_page);
+ SetPageSwapBacked(new_page);
+ err = __add_to_swap_cache(new_page, entry);
+ if (likely(!err)) {
+ radix_tree_preload_end();
+ lru_cache_add_anon(new_page);
+ *retpage = new_page;
+ return ZSWAP_SWAPCACHE_NEW;
+ }
+ radix_tree_preload_end();
+ ClearPageSwapBacked(new_page);
+ __clear_page_locked(new_page);
+ /*
+ * add_to_swap_cache() doesn't return -EEXIST, so we can safely
+ * clear SWAP_HAS_CACHE flag.
+ */
+ swapcache_free(entry, NULL);
+ } while (err != -ENOMEM);
+
+ if (new_page)
+ page_cache_release(new_page);
+ if (!found_page)
+ return ZSWAP_SWAPCACHE_NOMEM;
+ *retpage = found_page;
+ return ZSWAP_SWAPCACHE_EXIST;
+}
+
+/*
+ * Attempts to free an entry by adding a page to the swap cache,
+ * decompressing the entry data into the page, and issuing a
+ * bio write to write the page back to the swap device.
+ *
+ * This can be thought of as a "resumed writeback" of the page
+ * to the swap device. We are basically resuming the same swap
+ * writeback path that was intercepted with the frontswap_store()
+ * in the first place. After the page has been decompressed into
+ * the swap cache, the compressed version stored by zswap can be
+ * freed.
+ */
+static int zswap_writeback_entry(struct zbud_pool *pool, unsigned long handle)
+{
+ struct zswap_header *zhdr;
+ swp_entry_t swpentry;
+ struct zswap_tree *tree;
+ pgoff_t offset;
+ struct zswap_entry *entry;
+ struct page *page;
+ u8 *src, *dst;
+ unsigned int dlen;
+ int ret, refcount;
+ struct writeback_control wbc = {
+ .sync_mode = WB_SYNC_NONE,
+ };
+
+ /* extract swpentry from data */
+ zhdr = zbud_map(pool, handle);
+ swpentry = zhdr->swpentry; /* here */
+ zbud_unmap(pool, handle);
+ tree = zswap_trees[swp_type(swpentry)];
+ offset = swp_offset(swpentry);
+ BUG_ON(pool != tree->pool);
+
+ /* find and ref zswap entry */
+ spin_lock(&tree->lock);
+ entry = zswap_rb_search(&tree->rbroot, offset);
+ if (!entry) {
+ /* entry was invalidated */
+ spin_unlock(&tree->lock);
+ return 0;
+ }
+ zswap_entry_get(entry);
+ spin_unlock(&tree->lock);
+ BUG_ON(offset != entry->offset);
+
+ /* try to allocate swap cache page */
+ switch (zswap_get_swap_cache_page(swpentry, &page)) {
+ case ZSWAP_SWAPCACHE_NOMEM: /* no memory */
+ ret = -ENOMEM;
+ goto fail;
+
+ case ZSWAP_SWAPCACHE_EXIST: /* page is unlocked */
+ /* page is already in the swap cache, ignore for now */
+ page_cache_release(page);
+ ret = -EEXIST;
+ goto fail;
+
+ case ZSWAP_SWAPCACHE_NEW: /* page is locked */
+ /* decompress */
+ dlen = PAGE_SIZE;
+ src = (u8 *)zbud_map(tree->pool, entry->handle) +
+ sizeof(struct zswap_header);
+ dst = kmap_atomic(page);
+ ret = zswap_comp_op(ZSWAP_COMPOP_DECOMPRESS, src,
+ entry->length, dst, &dlen);
+ kunmap_atomic(dst);
+ zbud_unmap(tree->pool, entry->handle);
+ BUG_ON(ret);
+ BUG_ON(dlen != PAGE_SIZE);
+
+ /* page is up to date */
+ SetPageUptodate(page);
+ }
+
+ /* start writeback */
+ __swap_writepage(page, &wbc, end_swap_bio_write);
+ page_cache_release(page);
+ zswap_written_back_pages++;
+
+ spin_lock(&tree->lock);
+
+ /* drop local reference */
+ zswap_entry_put(entry);
+ /* drop the initial reference from entry creation */
+ refcount = zswap_entry_put(entry);
+
+ /*
+ * There are three possible values for refcount here:
+ * (1) refcount is 1, load is in progress, unlink from rbtree,
+ * load will free
+ * (2) refcount is 0, (normal case) entry is valid,
+ * remove from rbtree and free entry
+ * (3) refcount is -1, invalidate happened during writeback,
+ * free entry
+ */
+ if (refcount >= 0) {
+ /* no invalidate yet, remove from rbtree */
+ rb_erase(&entry->rbnode, &tree->rbroot);
+ }
+ spin_unlock(&tree->lock);
+ if (refcount <= 0) {
+ /* free the entry */
+ zswap_free_entry(tree, entry);
+ return 0;
+ }
+ return -EAGAIN;
+
+fail:
+ spin_lock(&tree->lock);
+ zswap_entry_put(entry);
+ spin_unlock(&tree->lock);
+ return ret;
+}
+
+/*********************************
+* frontswap hooks
+**********************************/
+/* attempts to compress and store an single page */
+static int zswap_frontswap_store(unsigned type, pgoff_t offset,
+ struct page *page)
+{
+ struct zswap_tree *tree = zswap_trees[type];
+ struct zswap_entry *entry, *dupentry;
+ int ret;
+ unsigned int dlen = PAGE_SIZE, len;
+ unsigned long handle;
+ char *buf;
+ u8 *src, *dst;
+ struct zswap_header *zhdr;
+
+ if (!tree) {
+ ret = -ENODEV;
+ goto reject;
+ }
+
+ /* reclaim space if needed */
+ if (zswap_is_full()) {
+ zswap_pool_limit_hit++;
+ if (zbud_reclaim_page(tree->pool, 8)) {
+ zswap_reject_reclaim_fail++;
+ ret = -ENOMEM;
+ goto reject;
+ }
+ }
+
+ /* allocate entry */
+ entry = zswap_entry_cache_alloc(GFP_KERNEL);
+ if (!entry) {
+ zswap_reject_kmemcache_fail++;
+ ret = -ENOMEM;
+ goto reject;
+ }
+
+ /* compress */
+ dst = get_cpu_var(zswap_dstmem);
+ src = kmap_atomic(page);
+ ret = zswap_comp_op(ZSWAP_COMPOP_COMPRESS, src, PAGE_SIZE, dst, &dlen);
+ kunmap_atomic(src);
+ if (ret) {
+ ret = -EINVAL;
+ goto freepage;
+ }
+
+ /* store */
+ len = dlen + sizeof(struct zswap_header);
+ ret = zbud_alloc(tree->pool, len, __GFP_NORETRY | __GFP_NOWARN,
+ &handle);
+ if (ret == -ENOSPC) {
+ zswap_reject_compress_poor++;
+ goto freepage;
+ }
+ if (ret) {
+ zswap_reject_alloc_fail++;
+ goto freepage;
+ }
+ zhdr = zbud_map(tree->pool, handle);
+ zhdr->swpentry = swp_entry(type, offset);
+ buf = (u8 *)(zhdr + 1);
+ memcpy(buf, dst, dlen);
+ zbud_unmap(tree->pool, handle);
+ put_cpu_var(zswap_dstmem);
+
+ /* populate entry */
+ entry->offset = offset;
+ entry->handle = handle;
+ entry->length = dlen;
+
+ /* map */
+ spin_lock(&tree->lock);
+ do {
+ ret = zswap_rb_insert(&tree->rbroot, entry, &dupentry);
+ if (ret == -EEXIST) {
+ zswap_duplicate_entry++;
+ /* remove from rbtree */
+ rb_erase(&dupentry->rbnode, &tree->rbroot);
+ if (!zswap_entry_put(dupentry)) {
+ /* free */
+ zswap_free_entry(tree, dupentry);
+ }
+ }
+ } while (ret == -EEXIST);
+ spin_unlock(&tree->lock);
+
+ /* update stats */
+ atomic_inc(&zswap_stored_pages);
+ zswap_pool_pages = zbud_get_pool_size(tree->pool);
+
+ return 0;
+
+freepage:
+ put_cpu_var(zswap_dstmem);
+ zswap_entry_cache_free(entry);
+reject:
+ return ret;
+}
+
+/*
+ * returns 0 if the page was successfully decompressed
+ * return -1 on entry not found or error
+*/
+static int zswap_frontswap_load(unsigned type, pgoff_t offset,
+ struct page *page)
+{
+ struct zswap_tree *tree = zswap_trees[type];
+ struct zswap_entry *entry;
+ u8 *src, *dst;
+ unsigned int dlen;
+ int refcount, ret;
+
+ /* find */
+ spin_lock(&tree->lock);
+ entry = zswap_rb_search(&tree->rbroot, offset);
+ if (!entry) {
+ /* entry was written back */
+ spin_unlock(&tree->lock);
+ return -1;
+ }
+ zswap_entry_get(entry);
+ spin_unlock(&tree->lock);
+
+ /* decompress */
+ dlen = PAGE_SIZE;
+ src = (u8 *)zbud_map(tree->pool, entry->handle) +
+ sizeof(struct zswap_header);
+ dst = kmap_atomic(page);
+ ret = zswap_comp_op(ZSWAP_COMPOP_DECOMPRESS, src, entry->length,
+ dst, &dlen);
+ kunmap_atomic(dst);
+ zbud_unmap(tree->pool, entry->handle);
+ BUG_ON(ret);
+
+ spin_lock(&tree->lock);
+ refcount = zswap_entry_put(entry);
+ if (likely(refcount)) {
+ spin_unlock(&tree->lock);
+ return 0;
+ }
+ spin_unlock(&tree->lock);
+
+ /*
+ * We don't have to unlink from the rbtree because
+ * zswap_writeback_entry() or zswap_frontswap_invalidate page()
+ * has already done this for us if we are the last reference.
+ */
+ /* free */
+
+ zswap_free_entry(tree, entry);
+
+ return 0;
+}
+
+/* frees an entry in zswap */
+static void zswap_frontswap_invalidate_page(unsigned type, pgoff_t offset)
+{
+ struct zswap_tree *tree = zswap_trees[type];
+ struct zswap_entry *entry;
+ int refcount;
+
+ /* find */
+ spin_lock(&tree->lock);
+ entry = zswap_rb_search(&tree->rbroot, offset);
+ if (!entry) {
+ /* entry was written back */
+ spin_unlock(&tree->lock);
+ return;
+ }
+
+ /* remove from rbtree */
+ rb_erase(&entry->rbnode, &tree->rbroot);
+
+ /* drop the initial reference from entry creation */
+ refcount = zswap_entry_put(entry);
+
+ spin_unlock(&tree->lock);
+
+ if (refcount) {
+ /* writeback in progress, writeback will free */
+ return;
+ }
+
+ /* free */
+ zswap_free_entry(tree, entry);
+}
+
+/* frees all zswap entries for the given swap type */
+static void zswap_frontswap_invalidate_area(unsigned type)
+{
+ struct zswap_tree *tree = zswap_trees[type];
+ struct rb_node *node;
+ struct zswap_entry *entry;
+
+ if (!tree)
+ return;
+
+ /* walk the tree and free everything */
+ spin_lock(&tree->lock);
+ /*
+ * TODO: Even though this code should not be executed because
+ * the try_to_unuse() in swapoff should have emptied the tree,
+ * it is very wasteful to rebalance the tree after every
+ * removal when we are freeing the whole tree.
+ *
+ * If post-order traversal code is ever added to the rbtree
+ * implementation, it should be used here.
+ */
+ while ((node = rb_first(&tree->rbroot))) {
+ entry = rb_entry(node, struct zswap_entry, rbnode);
+ rb_erase(&entry->rbnode, &tree->rbroot);
+ zbud_free(tree->pool, entry->handle);
+ zswap_entry_cache_free(entry);
+ atomic_dec(&zswap_stored_pages);
+ }
+ tree->rbroot = RB_ROOT;
+ spin_unlock(&tree->lock);
+}
+
+static struct zbud_ops zswap_zbud_ops = {
+ .evict = zswap_writeback_entry
+};
+
+static void zswap_frontswap_init(unsigned type)
+{
+ struct zswap_tree *tree;
+
+ tree = kzalloc(sizeof(struct zswap_tree), GFP_KERNEL);
+ if (!tree)
+ goto err;
+ tree->pool = zbud_create_pool(GFP_KERNEL, &zswap_zbud_ops);
+ if (!tree->pool)
+ goto freetree;
+ tree->rbroot = RB_ROOT;
+ spin_lock_init(&tree->lock);
+ zswap_trees[type] = tree;
+ return;
+
+freetree:
+ kfree(tree);
+err:
+ pr_err("alloc failed, zswap disabled for swap type %d\n", type);
+}
+
+static struct frontswap_ops zswap_frontswap_ops = {
+ .store = zswap_frontswap_store,
+ .load = zswap_frontswap_load,
+ .invalidate_page = zswap_frontswap_invalidate_page,
+ .invalidate_area = zswap_frontswap_invalidate_area,
+ .init = zswap_frontswap_init
+};
+
+/*********************************
+* debugfs functions
+**********************************/
+#ifdef CONFIG_DEBUG_FS
+#include <linux/debugfs.h>
+
+static struct dentry *zswap_debugfs_root;
+
+static int __init zswap_debugfs_init(void)
+{
+ if (!debugfs_initialized())
+ return -ENODEV;
+
+ zswap_debugfs_root = debugfs_create_dir("zswap", NULL);
+ if (!zswap_debugfs_root)
+ return -ENOMEM;
+
+ debugfs_create_u64("pool_limit_hit", S_IRUGO,
+ zswap_debugfs_root, &zswap_pool_limit_hit);
+ debugfs_create_u64("reject_reclaim_fail", S_IRUGO,
+ zswap_debugfs_root, &zswap_reject_reclaim_fail);
+ debugfs_create_u64("reject_alloc_fail", S_IRUGO,
+ zswap_debugfs_root, &zswap_reject_alloc_fail);
+ debugfs_create_u64("reject_kmemcache_fail", S_IRUGO,
+ zswap_debugfs_root, &zswap_reject_kmemcache_fail);
+ debugfs_create_u64("reject_compress_poor", S_IRUGO,
+ zswap_debugfs_root, &zswap_reject_compress_poor);
+ debugfs_create_u64("written_back_pages", S_IRUGO,
+ zswap_debugfs_root, &zswap_written_back_pages);
+ debugfs_create_u64("duplicate_entry", S_IRUGO,
+ zswap_debugfs_root, &zswap_duplicate_entry);
+ debugfs_create_u64("pool_pages", S_IRUGO,
+ zswap_debugfs_root, &zswap_pool_pages);
+ debugfs_create_atomic_t("stored_pages", S_IRUGO,
+ zswap_debugfs_root, &zswap_stored_pages);
+
+ return 0;
+}
+
+static void __exit zswap_debugfs_exit(void)
+{
+ debugfs_remove_recursive(zswap_debugfs_root);
+}
+#else
+static int __init zswap_debugfs_init(void)
+{
+ return 0;
+}
+
+static void __exit zswap_debugfs_exit(void) { }
+#endif
+
+/*********************************
+* module init and exit
+**********************************/
+static int __init init_zswap(void)
+{
+ if (!zswap_enabled)
+ return 0;
+
+ pr_info("loading zswap\n");
+ if (zswap_entry_cache_create()) {
+ pr_err("entry cache creation failed\n");
+ goto error;
+ }
+ if (zswap_comp_init()) {
+ pr_err("compressor initialization failed\n");
+ goto compfail;
+ }
+ if (zswap_cpu_init()) {
+ pr_err("per-cpu initialization failed\n");
+ goto pcpufail;
+ }
+ frontswap_register_ops(&zswap_frontswap_ops);
+ if (zswap_debugfs_init())
+ pr_warn("debugfs initialization failed\n");
+ return 0;
+pcpufail:
+ zswap_comp_exit();
+compfail:
+ zswap_entry_cache_destory();
+error:
+ return -ENOMEM;
+}
+/* must be late so crypto has time to come up */
+late_initcall(init_zswap);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Seth Jennings <[email protected]>");
+MODULE_DESCRIPTION("Compressed cache for swap pages");
--
1.7.9.5
zbud is an special purpose allocator for storing compressed pages. It is
designed to store up to two compressed pages per physical page. While this
design limits storage density, it has simple and deterministic reclaim
properties that make it preferable to a higher density approach when reclaim
will be used.
zbud works by storing compressed pages, or "zpages", together in pairs in a
single memory page called a "zbud page". The first buddy is "left
justifed" at the beginning of the zbud page, and the last buddy is "right
justified" at the end of the zbud page. The benefit is that if either
buddy is freed, the freed buddy space, coalesced with whatever slack space
that existed between the buddies, results in the largest possible free region
within the zbud page.
zbud also provides an attractive lower bound on density. The ratio of zpages
to zbud pages can not be less than 1. This ensures that zbud can never "do
harm" by using more pages to store zpages than the uncompressed zpages would
have used on their own.
This implementation is a rewrite of the zbud allocator internally used
by zcache in the driver/staging tree. The rewrite was necessary to
remove some of the zcache specific elements that were ingrained throughout
and provide a generic allocation interface that can later be used by
zsmalloc and others.
This patch adds zbud to mm/ for later use by zswap.
Signed-off-by: Seth Jennings <[email protected]>
Acked-by: Rik van Riel <[email protected]>
---
include/linux/zbud.h | 22 +++
mm/Kconfig | 10 +
mm/Makefile | 1 +
mm/zbud.c | 526 ++++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 559 insertions(+)
create mode 100644 include/linux/zbud.h
create mode 100644 mm/zbud.c
diff --git a/include/linux/zbud.h b/include/linux/zbud.h
new file mode 100644
index 0000000..2571a5c
--- /dev/null
+++ b/include/linux/zbud.h
@@ -0,0 +1,22 @@
+#ifndef _ZBUD_H_
+#define _ZBUD_H_
+
+#include <linux/types.h>
+
+struct zbud_pool;
+
+struct zbud_ops {
+ int (*evict)(struct zbud_pool *pool, unsigned long handle);
+};
+
+struct zbud_pool *zbud_create_pool(gfp_t gfp, struct zbud_ops *ops);
+void zbud_destroy_pool(struct zbud_pool *pool);
+int zbud_alloc(struct zbud_pool *pool, int size, gfp_t gfp,
+ unsigned long *handle);
+void zbud_free(struct zbud_pool *pool, unsigned long handle);
+int zbud_reclaim_page(struct zbud_pool *pool, unsigned int retries);
+void *zbud_map(struct zbud_pool *pool, unsigned long handle);
+void zbud_unmap(struct zbud_pool *pool, unsigned long handle);
+u64 zbud_get_pool_size(struct zbud_pool *pool);
+
+#endif /* _ZBUD_H_ */
diff --git a/mm/Kconfig b/mm/Kconfig
index e742d06..3367ac3 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -477,3 +477,13 @@ config FRONTSWAP
and swap data is stored as normal on the matching swap device.
If unsure, say Y to enable frontswap.
+
+config ZBUD
+ tristate
+ default n
+ help
+ A special purpose allocator for storing compressed pages.
+ It is designed to store up to two compressed pages per physical
+ page. While this design limits storage density, it has simple and
+ deterministic reclaim properties that make it preferable to a higher
+ density approach when reclaim will be used.
diff --git a/mm/Makefile b/mm/Makefile
index 72c5acb..95f0197 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -58,3 +58,4 @@ obj-$(CONFIG_DEBUG_KMEMLEAK) += kmemleak.o
obj-$(CONFIG_DEBUG_KMEMLEAK_TEST) += kmemleak-test.o
obj-$(CONFIG_CLEANCACHE) += cleancache.o
obj-$(CONFIG_MEMORY_ISOLATION) += page_isolation.o
+obj-$(CONFIG_ZBUD) += zbud.o
diff --git a/mm/zbud.c b/mm/zbud.c
new file mode 100644
index 0000000..d63ae6e
--- /dev/null
+++ b/mm/zbud.c
@@ -0,0 +1,526 @@
+/*
+ * zbud.c
+ *
+ * Copyright (C) 2013, Seth Jennings, IBM
+ *
+ * Concepts based on zcache internal zbud allocator by Dan Magenheimer.
+ *
+ * zbud is an special purpose allocator for storing compressed pages. Contrary
+ * to what its name may suggest, zbud is not a buddy allocator, but rather an
+ * allocator that "buddies" two compressed pages together in a single memory
+ * page.
+ *
+ * While this design limits storage density, it has simple and deterministic
+ * reclaim properties that make it preferable to a higher density approach when
+ * reclaim will be used.
+ *
+ * zbud works by storing compressed pages, or "zpages", together in pairs in a
+ * single memory page called a "zbud page". The first buddy is "left
+ * justifed" at the beginning of the zbud page, and the last buddy is "right
+ * justified" at the end of the zbud page. The benefit is that if either
+ * buddy is freed, the freed buddy space, coalesced with whatever slack space
+ * that existed between the buddies, results in the largest possible free region
+ * within the zbud page.
+ *
+ * zbud also provides an attractive lower bound on density. The ratio of zpages
+ * to zbud pages can not be less than 1. This ensures that zbud can never "do
+ * harm" by using more pages to store zpages than the uncompressed zpages would
+ * have used on their own.
+ *
+ * zbud pages are divided into "chunks". The size of the chunks is fixed at
+ * compile time and determined by NCHUNKS_ORDER below. Dividing zbud pages
+ * into chunks allows organizing unbuddied zbud pages into a manageable number
+ * of unbuddied lists according to the number of free chunks available in the
+ * zbud page.
+ *
+ * The zbud API differs from that of conventional allocators in that the
+ * allocation function, zbud_alloc(), returns an opaque handle to the user,
+ * not a dereferenceable pointer. The user must map the handle using
+ * zbud_map() in order to get a usable pointer by which to access the
+ * allocation data and unmap the handle with zbud_unmap() when operations
+ * on the allocation data are complete.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/atomic.h>
+#include <linux/list.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+#include <linux/preempt.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/zbud.h>
+
+/*****************
+ * Structures
+*****************/
+/*
+ * NCHUNKS_ORDER determines the internal allocation granularity, effectively
+ * adjusting internal fragmentation. It also determines the number of
+ * freelists maintained in each pool. NCHUNKS_ORDER of 6 means that the
+ * allocation granularity will be in chunks of size PAGE_SIZE/64, and there
+ * will be 64 freelists per pool.
+ */
+#define NCHUNKS_ORDER 6
+
+#define CHUNK_SHIFT (PAGE_SHIFT - NCHUNKS_ORDER)
+#define CHUNK_SIZE (1 << CHUNK_SHIFT)
+#define NCHUNKS (PAGE_SIZE >> CHUNK_SHIFT)
+#define ZHDR_SIZE_ALIGNED CHUNK_SIZE
+
+/**
+ * struct zbud_pool - stores metadata for each zbud pool
+ * @lock: protects all pool fields and first|last_chunk fields of any
+ * zbud page in the pool
+ * @unbuddied: array of lists tracking zbud pages that only contain one buddy;
+ * the lists each zbud page is added to depends on the size of
+ * its free region.
+ * @buddied: list tracking the zbud pages that contain two buddies;
+ * these zbud pages are full
+ * @lru: list tracking the zbud pages in LRU order by most recently
+ * added buddy.
+ * @pages_nr: number of zbud pages in the pool.
+ * @ops: pointer to a structure of user defined operations specified at
+ * pool creation time.
+ *
+ * This structure is allocated at pool creation time and maintains metadata
+ * pertaining to a particular zbud pool.
+ */
+struct zbud_pool {
+ spinlock_t lock;
+ struct list_head unbuddied[NCHUNKS];
+ struct list_head buddied;
+ struct list_head lru;
+ u64 pages_nr;
+ struct zbud_ops *ops;
+};
+
+/*
+ * struct zbud_header - zbud page metadata occupying the first chunk of each
+ * zbud page.
+ * @buddy: links the zbud page into the unbuddied/buddied lists in the pool
+ * @lru: links the zbud page into the lru list in the pool
+ * @first_chunks: the size of the first buddy in chunks, 0 if free
+ * @last_chunks: the size of the last buddy in chunks, 0 if free
+ */
+struct zbud_header {
+ struct list_head buddy;
+ struct list_head lru;
+ unsigned int first_chunks;
+ unsigned int last_chunks;
+ bool under_reclaim;
+};
+
+/*****************
+ * Helpers
+*****************/
+/* Just to make the code easier to read */
+enum buddy {
+ FIRST,
+ LAST
+};
+
+/* Converts an allocation size in bytes to size in zbud chunks */
+static int size_to_chunks(int size)
+{
+ return (size + CHUNK_SIZE - 1) >> CHUNK_SHIFT;
+}
+
+#define for_each_unbuddied_list(_iter, _begin) \
+ for ((_iter) = (_begin); (_iter) < NCHUNKS; (_iter)++)
+
+/* Initializes the zbud header of a newly allocated zbud page */
+static struct zbud_header *init_zbud_page(struct page *page)
+{
+ struct zbud_header *zhdr = page_address(page);
+ zhdr->first_chunks = 0;
+ zhdr->last_chunks = 0;
+ INIT_LIST_HEAD(&zhdr->buddy);
+ INIT_LIST_HEAD(&zhdr->lru);
+ return zhdr;
+}
+
+/* Resets the struct page fields and frees the page */
+static void free_zbud_page(struct zbud_header *zhdr)
+{
+ __free_page(virt_to_page(zhdr));
+}
+
+/*
+ * Encodes the handle of a particular buddy within a zbud page
+ * Pool lock should be held as this function accesses first|last_chunks
+ */
+static unsigned long encode_handle(struct zbud_header *zhdr, enum buddy bud)
+{
+ unsigned long handle;
+
+ /*
+ * For now, the encoded handle is actually just the pointer to the data
+ * but this might not always be the case. A little information hiding.
+ * Add CHUNK_SIZE to the handle if it is the first allocation to jump
+ * over the zbud header in the first chunk.
+ */
+ handle = (unsigned long)zhdr;
+ if (bud == FIRST)
+ /* skip over zbud header */
+ handle += ZHDR_SIZE_ALIGNED;
+ else /* bud == LAST */
+ handle += PAGE_SIZE - (zhdr->last_chunks << CHUNK_SHIFT);
+ return handle;
+}
+
+/* Returns the zbud page where a given handle is stored */
+static struct zbud_header *handle_to_zbud_header(unsigned long handle)
+{
+ return (struct zbud_header *)(handle & PAGE_MASK);
+}
+
+/* Returns the number of free chunks in a zbud page */
+static int num_free_chunks(struct zbud_header *zhdr)
+{
+ /*
+ * Rather than branch for different situations, just use the fact that
+ * free buddies have a length of zero to simplify everything. -1 at the
+ * end for the zbud header.
+ */
+ return NCHUNKS - zhdr->first_chunks - zhdr->last_chunks - 1;
+}
+
+/*****************
+ * API Functions
+*****************/
+/**
+ * zbud_create_pool() - create a new zbud pool
+ * @gfp: gfp flags when allocating the zbud pool structure
+ * @ops: user-defined operations for the zbud pool
+ *
+ * Return: pointer to the new zbud pool or NULL if the metadata allocation
+ * failed.
+ */
+struct zbud_pool *zbud_create_pool(gfp_t gfp, struct zbud_ops *ops)
+{
+ struct zbud_pool *pool;
+ int i;
+
+ pool = kmalloc(sizeof(struct zbud_pool), gfp);
+ if (!pool)
+ return NULL;
+ spin_lock_init(&pool->lock);
+ for_each_unbuddied_list(i, 0)
+ INIT_LIST_HEAD(&pool->unbuddied[i]);
+ INIT_LIST_HEAD(&pool->buddied);
+ INIT_LIST_HEAD(&pool->lru);
+ pool->pages_nr = 0;
+ pool->ops = ops;
+ return pool;
+}
+
+/**
+ * zbud_destroy_pool() - destroys an existing zbud pool
+ * @pool: the zbud pool to be destroyed
+ *
+ * The pool should be emptied before this function is called.
+ */
+void zbud_destroy_pool(struct zbud_pool *pool)
+{
+ kfree(pool);
+}
+
+/**
+ * zbud_alloc() - allocates a region of a given size
+ * @pool: zbud pool from which to allocate
+ * @size: size in bytes of the desired allocation
+ * @gfp: gfp flags used if the pool needs to grow
+ * @handle: handle of the new allocation
+ *
+ * This function will attempt to find a free region in the pool large enough to
+ * satisfy the allocation request. A search of the unbuddied lists is
+ * performed first. If no suitable free region is found, then a new page is
+ * allocated and added to the pool to satisfy the request.
+ *
+ * gfp should not set __GFP_HIGHMEM as highmem pages cannot be used
+ * as zbud pool pages.
+ *
+ * Return: 0 if success and handle is set, otherwise -EINVAL is the size or
+ * gfp arguments are invalid or -ENOMEM if the pool was unable to allocate
+ * a new page.
+ */
+int zbud_alloc(struct zbud_pool *pool, int size, gfp_t gfp,
+ unsigned long *handle)
+{
+ int chunks, i, freechunks;
+ struct zbud_header *zhdr = NULL;
+ enum buddy bud;
+ struct page *page;
+
+ if (size <= 0 || gfp & __GFP_HIGHMEM)
+ return -EINVAL;
+ if (size > PAGE_SIZE - ZHDR_SIZE_ALIGNED)
+ return -ENOSPC;
+ chunks = size_to_chunks(size);
+ spin_lock(&pool->lock);
+
+ /* First, try to find an unbuddied zbud page. */
+ zhdr = NULL;
+ for_each_unbuddied_list(i, chunks) {
+ if (!list_empty(&pool->unbuddied[i])) {
+ zhdr = list_first_entry(&pool->unbuddied[i],
+ struct zbud_header, buddy);
+ list_del(&zhdr->buddy);
+ if (zhdr->first_chunks == 0)
+ bud = FIRST;
+ else
+ bud = LAST;
+ goto found;
+ }
+ }
+
+ /* Couldn't find unbuddied zbud page, create new one */
+ spin_unlock(&pool->lock);
+ page = alloc_page(gfp);
+ if (!page)
+ return -ENOMEM;
+ spin_lock(&pool->lock);
+ pool->pages_nr++;
+ zhdr = init_zbud_page(page);
+ bud = FIRST;
+
+found:
+ if (bud == FIRST)
+ zhdr->first_chunks = chunks;
+ else
+ zhdr->last_chunks = chunks;
+
+ if (zhdr->first_chunks == 0 || zhdr->last_chunks == 0) {
+ /* Add to unbuddied list */
+ freechunks = num_free_chunks(zhdr);
+ list_add(&zhdr->buddy, &pool->unbuddied[freechunks]);
+ } else {
+ /* Add to buddied list */
+ list_add(&zhdr->buddy, &pool->buddied);
+ }
+
+ /* Add/move zbud page to beginning of LRU */
+ if (!list_empty(&zhdr->lru))
+ list_del(&zhdr->lru);
+ list_add(&zhdr->lru, &pool->lru);
+
+ *handle = encode_handle(zhdr, bud);
+ spin_unlock(&pool->lock);
+
+ return 0;
+}
+
+/**
+ * zbud_free() - frees the allocation associated with the given handle
+ * @pool: pool in which the allocation resided
+ * @handle: handle associated with the allocation returned by zbud_alloc()
+ *
+ * In the case that the zbud page in which the allocation resides is under
+ * reclaim, as indicated by the PG_reclaim flag being set, this function
+ * only sets the first|last_chunks to 0. The page is actually freed
+ * once both buddies are evicted (see zbud_reclaim_page() below).
+ */
+void zbud_free(struct zbud_pool *pool, unsigned long handle)
+{
+ struct zbud_header *zhdr;
+ int freechunks;
+
+ spin_lock(&pool->lock);
+ zhdr = handle_to_zbud_header(handle);
+
+ /* If first buddy, handle will be page aligned */
+ if ((handle - ZHDR_SIZE_ALIGNED) & ~PAGE_MASK)
+ zhdr->last_chunks = 0;
+ else
+ zhdr->first_chunks = 0;
+
+ if (zhdr->under_reclaim) {
+ /* zbud page is under reclaim, reclaim will free */
+ spin_unlock(&pool->lock);
+ return;
+ }
+
+ /* Remove from existing buddy list */
+ list_del(&zhdr->buddy);
+
+ if (zhdr->first_chunks == 0 && zhdr->last_chunks == 0) {
+ /* zbud page is empty, free */
+ list_del(&zhdr->lru);
+ free_zbud_page(zhdr);
+ pool->pages_nr--;
+ } else {
+ /* Add to unbuddied list */
+ freechunks = num_free_chunks(zhdr);
+ list_add(&zhdr->buddy, &pool->unbuddied[freechunks]);
+ }
+
+ spin_unlock(&pool->lock);
+}
+
+#define list_tail_entry(ptr, type, member) \
+ list_entry((ptr)->prev, type, member)
+
+/**
+ * zbud_reclaim_page() - evicts allocations from a pool page and frees it
+ * @pool: pool from which a page will attempt to be evicted
+ * @retires: number of pages on the LRU list for which eviction will
+ * be attempted before failing
+ *
+ * zbud reclaim is different from normal system reclaim in that the reclaim is
+ * done from the bottom, up. This is because only the bottom layer, zbud, has
+ * information on how the allocations are organized within each zbud page. This
+ * has the potential to create interesting locking situations between zbud and
+ * the user, however.
+ *
+ * To avoid these, this is how zbud_reclaim_page() should be called:
+
+ * The user detects a page should be reclaimed and calls zbud_reclaim_page().
+ * zbud_reclaim_page() will remove a zbud page from the pool LRU list and call
+ * the user-defined eviction handler with the pool and handle as arguments.
+ *
+ * If the handle can not be evicted, the eviction handler should return
+ * non-zero. zbud_reclaim_page() will add the zbud page back to the
+ * appropriate list and try the next zbud page on the LRU up to
+ * a user defined number of retries.
+ *
+ * If the handle is successfully evicted, the eviction handler should
+ * return 0 _and_ should have called zbud_free() on the handle. zbud_free()
+ * contains logic to delay freeing the page if the page is under reclaim,
+ * as indicated by the setting of the PG_reclaim flag on the underlying page.
+ *
+ * If all buddies in the zbud page are successfully evicted, then the
+ * zbud page can be freed.
+ *
+ * Returns: 0 if page is successfully freed, otherwise -EINVAL if there are
+ * no pages to evict or an eviction handler is not registered, -EAGAIN if
+ * the retry limit was hit.
+ */
+int zbud_reclaim_page(struct zbud_pool *pool, unsigned int retries)
+{
+ int i, ret, freechunks;
+ struct zbud_header *zhdr;
+ unsigned long first_handle = 0, last_handle = 0;
+
+ spin_lock(&pool->lock);
+ if (!pool->ops || !pool->ops->evict || list_empty(&pool->lru) ||
+ retries == 0) {
+ spin_unlock(&pool->lock);
+ return -EINVAL;
+ }
+ for (i = 0; i < retries; i++) {
+ zhdr = list_tail_entry(&pool->lru, struct zbud_header, lru);
+ list_del(&zhdr->lru);
+ list_del(&zhdr->buddy);
+ /* Protect zbud page against free */
+ zhdr->under_reclaim = true;
+ /*
+ * We need encode the handles before unlocking, since we can
+ * race with free that will set (first|last)_chunks to 0
+ */
+ first_handle = 0;
+ last_handle = 0;
+ if (zhdr->first_chunks)
+ first_handle = encode_handle(zhdr, FIRST);
+ if (zhdr->last_chunks)
+ last_handle = encode_handle(zhdr, LAST);
+ spin_unlock(&pool->lock);
+
+ /* Issue the eviction callback(s) */
+ if (first_handle) {
+ ret = pool->ops->evict(pool, first_handle);
+ if (ret)
+ goto next;
+ }
+ if (last_handle) {
+ ret = pool->ops->evict(pool, last_handle);
+ if (ret)
+ goto next;
+ }
+next:
+ spin_lock(&pool->lock);
+ zhdr->under_reclaim = false;
+ if (zhdr->first_chunks == 0 && zhdr->last_chunks == 0) {
+ /*
+ * Both buddies are now free, free the zbud page and
+ * return success.
+ */
+ free_zbud_page(zhdr);
+ pool->pages_nr--;
+ spin_unlock(&pool->lock);
+ return 0;
+ } else if (zhdr->first_chunks == 0 ||
+ zhdr->last_chunks == 0) {
+ /* add to unbuddied list */
+ freechunks = num_free_chunks(zhdr);
+ list_add(&zhdr->buddy, &pool->unbuddied[freechunks]);
+ } else {
+ /* add to buddied list */
+ list_add(&zhdr->buddy, &pool->buddied);
+ }
+
+ /* add to beginning of LRU */
+ list_add(&zhdr->lru, &pool->lru);
+ }
+ spin_unlock(&pool->lock);
+ return -EAGAIN;
+}
+
+/**
+ * zbud_map() - maps the allocation associated with the given handle
+ * @pool: pool in which the allocation resides
+ * @handle: handle associated with the allocation to be mapped
+ *
+ * While trivial for zbud, the mapping functions for others allocators
+ * implementing this allocation API could have more complex information encoded
+ * in the handle and could create temporary mappings to make the data
+ * accessible to the user.
+ *
+ * Returns: a pointer to the mapped allocation
+ */
+void *zbud_map(struct zbud_pool *pool, unsigned long handle)
+{
+ return (void *)(handle);
+}
+
+/**
+ * zbud_unmap() - maps the allocation associated with the given handle
+ * @pool: pool in which the allocation resides
+ * @handle: handle associated with the allocation to be unmapped
+ */
+void zbud_unmap(struct zbud_pool *pool, unsigned long handle)
+{
+}
+
+/**
+ * zbud_get_pool_size() - gets the zbud pool size in pages
+ * @pool: pool whose size is being queried
+ *
+ * Returns: size in pages of the given pool. The pool lock need not be
+ * taken to access pages_nr.
+ */
+u64 zbud_get_pool_size(struct zbud_pool *pool)
+{
+ return pool->pages_nr;
+}
+
+static int __init init_zbud(void)
+{
+ /* Make sure the zbud header will fit in one chunk */
+ BUILD_BUG_ON(sizeof(struct zbud_header) > ZHDR_SIZE_ALIGNED);
+ pr_info("loaded\n");
+ return 0;
+}
+
+static void __exit exit_zbud(void)
+{
+ pr_info("unloaded\n");
+}
+
+module_init(init_zbud);
+module_exit(exit_zbud);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Seth Jennings <[email protected]>");
+MODULE_DESCRIPTION("Buddy Allocator for Compressed Pages");
--
1.7.9.5
This patch adds the documentation file for the zswap functionality
Signed-off-by: Seth Jennings <[email protected]>
Acked-by: Rik van Riel <[email protected]>
---
Documentation/vm/zswap.txt | 68 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
create mode 100644 Documentation/vm/zswap.txt
diff --git a/Documentation/vm/zswap.txt b/Documentation/vm/zswap.txt
new file mode 100644
index 0000000..7e492d8
--- /dev/null
+++ b/Documentation/vm/zswap.txt
@@ -0,0 +1,68 @@
+Overview:
+
+Zswap is a lightweight compressed cache for swap pages. It takes pages that are
+in the process of being swapped out and attempts to compress them into a
+dynamically allocated RAM-based memory pool. zswap basically trades CPU cycles
+for potentially reduced swap I/O. This trade-off can also result in a
+significant performance improvement if reads from the compressed cache are
+faster than reads from a swap device.
+
+NOTE: Zswap is a new feature as of v3.11 and interacts heavily with memory
+reclaim. This interaction has not be fully explored on the large set of
+potential configurations and workloads that exist. For this reason, zswap
+is a work in progress and should be considered experimental.
+
+Some potential benefits:
+* Desktop/laptop users with limited RAM capacities can mitigate the
+ performance impact of swapping.
+* Overcommitted guests that share a common I/O resource can
+ dramatically reduce their swap I/O pressure, avoiding heavy handed I/O
+ throttling by the hypervisor. This allows more work to get done with less
+ impact to the guest workload and guests sharing the I/O subsystem
+* Users with SSDs as swap devices can extend the life of the device by
+ drastically reducing life-shortening writes.
+
+Zswap evicts pages from compressed cache on an LRU basis to the backing swap
+device when the compressed pool reaches it size limit. This requirement had
+been identified in prior community discussions.
+
+To enabled zswap, the "enabled" attribute must be set to 1 at boot time. e.g.
+zswap.enabled=1
+
+Design:
+
+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
+return 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.
+
+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
+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.
+
+During a page fault on a PTE that is a swap entry, frontswap calls the zswap
+load function to decompress the page into the page allocated by the page fault
+handler.
+
+Once there are no PTEs referencing a swap page stored in zswap (i.e. the count
+in the swap_map goes to 0) the swap code calls the zswap invalidate function,
+via frontswap, to free the compressed entry.
+
+Zswap seeks to be simple in its policies. Sysfs attributes allow for one user
+controlled policies:
+* 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
+
+A debugfs interface is provided for various statistic about pool size, number
+of pages stored, and various counters for the reasons pages are rejected.
--
1.7.9.5
Hi Seth,
On 06/04/2013 04:33 AM, Seth Jennings wrote:
> zbud is an special purpose allocator for storing compressed pages. It is
> designed to store up to two compressed pages per physical page. While this
> design limits storage density, it has simple and deterministic reclaim
> properties that make it preferable to a higher density approach when reclaim
> will be used.
>
> zbud works by storing compressed pages, or "zpages", together in pairs in a
> single memory page called a "zbud page". The first buddy is "left
> justifed" at the beginning of the zbud page, and the last buddy is "right
> justified" at the end of the zbud page. The benefit is that if either
> buddy is freed, the freed buddy space, coalesced with whatever slack space
> that existed between the buddies, results in the largest possible free region
> within the zbud page.
>
> zbud also provides an attractive lower bound on density. The ratio of zpages
> to zbud pages can not be less than 1. This ensures that zbud can never "do
> harm" by using more pages to store zpages than the uncompressed zpages would
> have used on their own.
>
> This implementation is a rewrite of the zbud allocator internally used
> by zcache in the driver/staging tree. The rewrite was necessary to
> remove some of the zcache specific elements that were ingrained throughout
> and provide a generic allocation interface that can later be used by
> zsmalloc and others.
>
> This patch adds zbud to mm/ for later use by zswap.
>
> Signed-off-by: Seth Jennings <[email protected]>
> Acked-by: Rik van Riel <[email protected]>
> ---
> include/linux/zbud.h | 22 +++
> mm/Kconfig | 10 +
> mm/Makefile | 1 +
> mm/zbud.c | 526 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 559 insertions(+)
> create mode 100644 include/linux/zbud.h
> create mode 100644 mm/zbud.c
>
> diff --git a/include/linux/zbud.h b/include/linux/zbud.h
> new file mode 100644
> index 0000000..2571a5c
> --- /dev/null
> +++ b/include/linux/zbud.h
> @@ -0,0 +1,22 @@
> +#ifndef _ZBUD_H_
> +#define _ZBUD_H_
> +
> +#include <linux/types.h>
> +
> +struct zbud_pool;
> +
> +struct zbud_ops {
> + int (*evict)(struct zbud_pool *pool, unsigned long handle);
> +};
> +
> +struct zbud_pool *zbud_create_pool(gfp_t gfp, struct zbud_ops *ops);
> +void zbud_destroy_pool(struct zbud_pool *pool);
> +int zbud_alloc(struct zbud_pool *pool, int size, gfp_t gfp,
> + unsigned long *handle);
> +void zbud_free(struct zbud_pool *pool, unsigned long handle);
> +int zbud_reclaim_page(struct zbud_pool *pool, unsigned int retries);
> +void *zbud_map(struct zbud_pool *pool, unsigned long handle);
> +void zbud_unmap(struct zbud_pool *pool, unsigned long handle);
> +u64 zbud_get_pool_size(struct zbud_pool *pool);
> +
> +#endif /* _ZBUD_H_ */
> diff --git a/mm/Kconfig b/mm/Kconfig
> index e742d06..3367ac3 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -477,3 +477,13 @@ config FRONTSWAP
> and swap data is stored as normal on the matching swap device.
>
> If unsure, say Y to enable frontswap.
> +
> +config ZBUD
> + tristate
> + default n
> + help
> + A special purpose allocator for storing compressed pages.
> + It is designed to store up to two compressed pages per physical
> + page. While this design limits storage density, it has simple and
> + deterministic reclaim properties that make it preferable to a higher
> + density approach when reclaim will be used.
> diff --git a/mm/Makefile b/mm/Makefile
> index 72c5acb..95f0197 100644
> --- a/mm/Makefile
> +++ b/mm/Makefile
> @@ -58,3 +58,4 @@ obj-$(CONFIG_DEBUG_KMEMLEAK) += kmemleak.o
> obj-$(CONFIG_DEBUG_KMEMLEAK_TEST) += kmemleak-test.o
> obj-$(CONFIG_CLEANCACHE) += cleancache.o
> obj-$(CONFIG_MEMORY_ISOLATION) += page_isolation.o
> +obj-$(CONFIG_ZBUD) += zbud.o
> diff --git a/mm/zbud.c b/mm/zbud.c
> new file mode 100644
> index 0000000..d63ae6e
> --- /dev/null
> +++ b/mm/zbud.c
> @@ -0,0 +1,526 @@
> +/*
> + * zbud.c
> + *
> + * Copyright (C) 2013, Seth Jennings, IBM
> + *
> + * Concepts based on zcache internal zbud allocator by Dan Magenheimer.
> + *
> + * zbud is an special purpose allocator for storing compressed pages. Contrary
> + * to what its name may suggest, zbud is not a buddy allocator, but rather an
> + * allocator that "buddies" two compressed pages together in a single memory
> + * page.
> + *
> + * While this design limits storage density, it has simple and deterministic
> + * reclaim properties that make it preferable to a higher density approach when
> + * reclaim will be used.
> + *
> + * zbud works by storing compressed pages, or "zpages", together in pairs in a
> + * single memory page called a "zbud page". The first buddy is "left
> + * justifed" at the beginning of the zbud page, and the last buddy is "right
> + * justified" at the end of the zbud page. The benefit is that if either
> + * buddy is freed, the freed buddy space, coalesced with whatever slack space
> + * that existed between the buddies, results in the largest possible free region
> + * within the zbud page.
> + *
> + * zbud also provides an attractive lower bound on density. The ratio of zpages
> + * to zbud pages can not be less than 1. This ensures that zbud can never "do
> + * harm" by using more pages to store zpages than the uncompressed zpages would
> + * have used on their own.
> + *
> + * zbud pages are divided into "chunks". The size of the chunks is fixed at
> + * compile time and determined by NCHUNKS_ORDER below. Dividing zbud pages
> + * into chunks allows organizing unbuddied zbud pages into a manageable number
> + * of unbuddied lists according to the number of free chunks available in the
> + * zbud page.
> + *
> + * The zbud API differs from that of conventional allocators in that the
> + * allocation function, zbud_alloc(), returns an opaque handle to the user,
> + * not a dereferenceable pointer. The user must map the handle using
> + * zbud_map() in order to get a usable pointer by which to access the
> + * allocation data and unmap the handle with zbud_unmap() when operations
> + * on the allocation data are complete.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include <linux/atomic.h>
> +#include <linux/list.h>
> +#include <linux/mm.h>
> +#include <linux/module.h>
> +#include <linux/preempt.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +#include <linux/zbud.h>
> +
> +/*****************
> + * Structures
> +*****************/
> +/*
> + * NCHUNKS_ORDER determines the internal allocation granularity, effectively
> + * adjusting internal fragmentation. It also determines the number of
> + * freelists maintained in each pool. NCHUNKS_ORDER of 6 means that the
> + * allocation granularity will be in chunks of size PAGE_SIZE/64, and there
> + * will be 64 freelists per pool.
> + */
> +#define NCHUNKS_ORDER 6
> +
> +#define CHUNK_SHIFT (PAGE_SHIFT - NCHUNKS_ORDER)
> +#define CHUNK_SIZE (1 << CHUNK_SHIFT)
> +#define NCHUNKS (PAGE_SIZE >> CHUNK_SHIFT)
> +#define ZHDR_SIZE_ALIGNED CHUNK_SIZE
> +
> +/**
> + * struct zbud_pool - stores metadata for each zbud pool
> + * @lock: protects all pool fields and first|last_chunk fields of any
> + * zbud page in the pool
> + * @unbuddied: array of lists tracking zbud pages that only contain one buddy;
> + * the lists each zbud page is added to depends on the size of
> + * its free region.
> + * @buddied: list tracking the zbud pages that contain two buddies;
> + * these zbud pages are full
> + * @lru: list tracking the zbud pages in LRU order by most recently
> + * added buddy.
> + * @pages_nr: number of zbud pages in the pool.
> + * @ops: pointer to a structure of user defined operations specified at
> + * pool creation time.
> + *
> + * This structure is allocated at pool creation time and maintains metadata
> + * pertaining to a particular zbud pool.
> + */
> +struct zbud_pool {
> + spinlock_t lock;
> + struct list_head unbuddied[NCHUNKS];
> + struct list_head buddied;
> + struct list_head lru;
> + u64 pages_nr;
> + struct zbud_ops *ops;
> +};
> +
> +/*
> + * struct zbud_header - zbud page metadata occupying the first chunk of each
> + * zbud page.
> + * @buddy: links the zbud page into the unbuddied/buddied lists in the pool
> + * @lru: links the zbud page into the lru list in the pool
> + * @first_chunks: the size of the first buddy in chunks, 0 if free
> + * @last_chunks: the size of the last buddy in chunks, 0 if free
Missing under_reclaim.
> + */
> +struct zbud_header {
> + struct list_head buddy;
> + struct list_head lru;
> + unsigned int first_chunks;
> + unsigned int last_chunks;
> + bool under_reclaim;
> +};
> +
> +/*****************
> + * Helpers
> +*****************/
> +/* Just to make the code easier to read */
> +enum buddy {
> + FIRST,
> + LAST
> +};
> +
> +/* Converts an allocation size in bytes to size in zbud chunks */
> +static int size_to_chunks(int size)
> +{
> + return (size + CHUNK_SIZE - 1) >> CHUNK_SHIFT;
> +}
> +
> +#define for_each_unbuddied_list(_iter, _begin) \
> + for ((_iter) = (_begin); (_iter) < NCHUNKS; (_iter)++)
> +
> +/* Initializes the zbud header of a newly allocated zbud page */
> +static struct zbud_header *init_zbud_page(struct page *page)
> +{
> + struct zbud_header *zhdr = page_address(page);
> + zhdr->first_chunks = 0;
> + zhdr->last_chunks = 0;
> + INIT_LIST_HEAD(&zhdr->buddy);
> + INIT_LIST_HEAD(&zhdr->lru);
> + return zhdr;
> +}
> +
> +/* Resets the struct page fields and frees the page */
> +static void free_zbud_page(struct zbud_header *zhdr)
> +{
> + __free_page(virt_to_page(zhdr));
> +}
> +
> +/*
> + * Encodes the handle of a particular buddy within a zbud page
> + * Pool lock should be held as this function accesses first|last_chunks
> + */
> +static unsigned long encode_handle(struct zbud_header *zhdr, enum buddy bud)
> +{
> + unsigned long handle;
> +
> + /*
> + * For now, the encoded handle is actually just the pointer to the data
> + * but this might not always be the case. A little information hiding.
> + * Add CHUNK_SIZE to the handle if it is the first allocation to jump
> + * over the zbud header in the first chunk.
> + */
> + handle = (unsigned long)zhdr;
> + if (bud == FIRST)
> + /* skip over zbud header */
> + handle += ZHDR_SIZE_ALIGNED;
> + else /* bud == LAST */
> + handle += PAGE_SIZE - (zhdr->last_chunks << CHUNK_SHIFT);
> + return handle;
> +}
> +
> +/* Returns the zbud page where a given handle is stored */
> +static struct zbud_header *handle_to_zbud_header(unsigned long handle)
> +{
> + return (struct zbud_header *)(handle & PAGE_MASK);
> +}
> +
> +/* Returns the number of free chunks in a zbud page */
> +static int num_free_chunks(struct zbud_header *zhdr)
> +{
> + /*
> + * Rather than branch for different situations, just use the fact that
> + * free buddies have a length of zero to simplify everything. -1 at the
> + * end for the zbud header.
> + */
> + return NCHUNKS - zhdr->first_chunks - zhdr->last_chunks - 1;
> +}
> +
> +/*****************
> + * API Functions
> +*****************/
> +/**
> + * zbud_create_pool() - create a new zbud pool
> + * @gfp: gfp flags when allocating the zbud pool structure
> + * @ops: user-defined operations for the zbud pool
> + *
> + * Return: pointer to the new zbud pool or NULL if the metadata allocation
> + * failed.
> + */
> +struct zbud_pool *zbud_create_pool(gfp_t gfp, struct zbud_ops *ops)
> +{
> + struct zbud_pool *pool;
> + int i;
> +
> + pool = kmalloc(sizeof(struct zbud_pool), gfp);
> + if (!pool)
> + return NULL;
> + spin_lock_init(&pool->lock);
> + for_each_unbuddied_list(i, 0)
> + INIT_LIST_HEAD(&pool->unbuddied[i]);
> + INIT_LIST_HEAD(&pool->buddied);
> + INIT_LIST_HEAD(&pool->lru);
> + pool->pages_nr = 0;
> + pool->ops = ops;
> + return pool;
> +}
> +
> +/**
> + * zbud_destroy_pool() - destroys an existing zbud pool
> + * @pool: the zbud pool to be destroyed
> + *
> + * The pool should be emptied before this function is called.
> + */
> +void zbud_destroy_pool(struct zbud_pool *pool)
> +{
> + kfree(pool);
> +}
> +
> +/**
> + * zbud_alloc() - allocates a region of a given size
> + * @pool: zbud pool from which to allocate
> + * @size: size in bytes of the desired allocation
> + * @gfp: gfp flags used if the pool needs to grow
> + * @handle: handle of the new allocation
> + *
> + * This function will attempt to find a free region in the pool large enough to
> + * satisfy the allocation request. A search of the unbuddied lists is
> + * performed first. If no suitable free region is found, then a new page is
> + * allocated and added to the pool to satisfy the request.
> + *
> + * gfp should not set __GFP_HIGHMEM as highmem pages cannot be used
> + * as zbud pool pages.
> + *
> + * Return: 0 if success and handle is set, otherwise -EINVAL is the size or
> + * gfp arguments are invalid or -ENOMEM if the pool was unable to allocate
> + * a new page.
> + */
> +int zbud_alloc(struct zbud_pool *pool, int size, gfp_t gfp,
> + unsigned long *handle)
> +{
> + int chunks, i, freechunks;
> + struct zbud_header *zhdr = NULL;
> + enum buddy bud;
> + struct page *page;
> +
> + if (size <= 0 || gfp & __GFP_HIGHMEM)
> + return -EINVAL;
> + if (size > PAGE_SIZE - ZHDR_SIZE_ALIGNED)
> + return -ENOSPC;
> + chunks = size_to_chunks(size);
> + spin_lock(&pool->lock);
> +
> + /* First, try to find an unbuddied zbud page. */
> + zhdr = NULL;
> + for_each_unbuddied_list(i, chunks) {
> + if (!list_empty(&pool->unbuddied[i])) {
> + zhdr = list_first_entry(&pool->unbuddied[i],
> + struct zbud_header, buddy);
> + list_del(&zhdr->buddy);
> + if (zhdr->first_chunks == 0)
> + bud = FIRST;
> + else
> + bud = LAST;
> + goto found;
> + }
> + }
> +
> + /* Couldn't find unbuddied zbud page, create new one */
How about moving zswap_is_full() to here.
if (zswap_is_full()) {
/* Don't alloc any new page, try to reclaim and direct use the
reclaimed page instead */
}
> + spin_unlock(&pool->lock);
> + page = alloc_page(gfp);
> + if (!page)
> + return -ENOMEM;
> + spin_lock(&pool->lock);
> + pool->pages_nr++;
> + zhdr = init_zbud_page(page);
> + bud = FIRST;
> +
> +found:
> + if (bud == FIRST)
> + zhdr->first_chunks = chunks;
> + else
> + zhdr->last_chunks = chunks;
> +
> + if (zhdr->first_chunks == 0 || zhdr->last_chunks == 0) {
> + /* Add to unbuddied list */
> + freechunks = num_free_chunks(zhdr);
> + list_add(&zhdr->buddy, &pool->unbuddied[freechunks]);
> + } else {
> + /* Add to buddied list */
> + list_add(&zhdr->buddy, &pool->buddied);
> + }
> +
> + /* Add/move zbud page to beginning of LRU */
> + if (!list_empty(&zhdr->lru))
> + list_del(&zhdr->lru);
> + list_add(&zhdr->lru, &pool->lru);
> +
> + *handle = encode_handle(zhdr, bud);
> + spin_unlock(&pool->lock);
> +
> + return 0;
> +}
> +
It looks good for me except two things.
One is about what the performance might be after the zswap pool is full.
The other is still about the 20% limit of zswap pool size.
I need more time to test it.
--
Regards,
-Bob
On Wed, Jun 05, 2013 at 02:43:28PM +0800, Bob Liu wrote:
> Hi Seth,
>
> On 06/04/2013 04:33 AM, Seth Jennings wrote:
> > + /* Couldn't find unbuddied zbud page, create new one */
>
> How about moving zswap_is_full() to here.
>
> if (zswap_is_full()) {
> /* Don't alloc any new page, try to reclaim and direct use the
> reclaimed page instead */
Yes, this is at the top of the list for improvements.
I have already started on this work and it isn't quite as simple as it seems.
The difficulty rises from the fact that, for now, zswap uses per-cpu
compression buffers which require preemption to be disabled. This prevents the
calling zbud_reclaim_page() in zbud_alloc() because the eviction handler for
the user may do something that can wait; an allocation with GFP_WAIT for
example.
So it's going to take some massaging in the zswap layer to get that to work.
It's very doable. Just not in this patchset without causing a lot of code
thrash.
> }
>
> > + spin_unlock(&pool->lock);
> > + page = alloc_page(gfp);
> > + if (!page)
> > + return -ENOMEM;
> > + spin_lock(&pool->lock);
> > + pool->pages_nr++;
> > + zhdr = init_zbud_page(page);
> > + bud = FIRST;
<snip>
>
> It looks good for me except two things.
> One is about what the performance might be after the zswap pool is full.
> The other is still about the 20% limit of zswap pool size.
Yep, working on both of them.
Seth
Hi Seth,
On 06/04/2013 04:33 AM, Seth Jennings wrote:
> This is the latest version of the zswap patchset for compressed swap caching.
> This is submitted for merging into linux-next and inclusion in v3.11.
>
Have you noticed that pool_pages >> stored_pages, like this:
[root@ca-dev32 zswap]# cat *
0
424057
99538
0
2749448
0
24
60018
16837
[root@ca-dev32 zswap]# cat pool_pages
97372
[root@ca-dev32 zswap]# cat stored_pages
53701
[root@ca-dev32 zswap]#
I think it's unreasonable to use more pool pages than stored pages!
Regards,
-Bob
On Thu, Jun 13, 2013 at 08:34:38PM +0800, Bob Liu wrote:
> Hi Seth,
>
> On 06/04/2013 04:33 AM, Seth Jennings wrote:
> > This is the latest version of the zswap patchset for compressed swap caching.
> > This is submitted for merging into linux-next and inclusion in v3.11.
> >
>
> Have you noticed that pool_pages >> stored_pages, like this:
> [root@ca-dev32 zswap]# cat *
> 0
> 424057
> 99538
> 0
> 2749448
> 0
> 24
> 60018
> 16837
> [root@ca-dev32 zswap]# cat pool_pages
> 97372
> [root@ca-dev32 zswap]# cat stored_pages
> 53701
> [root@ca-dev32 zswap]#
>
> I think it's unreasonable to use more pool pages than stored pages!
Gah, in the moving of the zbud metadata for v13, I forgot to init the new
under_reclaim field of the zbud header. Patch going out now.
Thanks for reporting!
Seth
Hi Seth,
On Tue, Jun 4, 2013 at 4:33 AM, Seth Jennings
<[email protected]> wrote:
> zswap is a thin backend for frontswap that takes pages that are in the process
> of being swapped out and attempts to compress them and store them in a
> RAM-based memory pool. This can result in a significant I/O reduction on the
> swap device and, in the case where decompressing from RAM is faster than
> reading from the swap device, can also improve workload performance.
>
> It also has support for evicting swap pages that are currently compressed in
> zswap to the swap device on an LRU(ish) basis. This functionality makes zswap a
> true cache in that, once the cache is full, the oldest pages can be moved out
> of zswap to the swap device so newer pages can be compressed and stored in
> zswap.
>
> This patch adds the zswap driver to mm/
>
Do you have any more benchmark can share with me ? To figure out that
we can benefit from zswap.
I found zswap will cause performance drop when using mmtests-0.10 to test it.
The config file I'm using is: config-global-dhp__parallelio-memcachetest
The result is:
(v3.10-rc4-2G-nozswap was without zswap but the performance is better.)
v3.10-rc4 v3.10-rc4
2G-zswap-base 2G-nozswap
Ops memcachetest-0M 604.00 ( 0.00%) 1077.00 ( 78.31%)
Ops memcachetest-198M 630.00 ( 0.00%) 1007.00 ( 59.84%)
Ops memcachetest-430M 609.00 ( 0.00%) 939.00 ( 54.19%)
Ops memcachetest-661M 604.00 ( 0.00%) 845.00 ( 39.90%)
Ops memcachetest-893M 591.00 ( 0.00%) 839.00 ( 41.96%)
Ops memcachetest-1125M 599.00 ( 0.00%) 781.00 ( 30.38%)
Ops memcachetest-1356M 588.00 ( 0.00%) 771.00 ( 31.12%)
Ops io-duration-0M 0.00 ( 0.00%) 1.00 (-99.00%)
Ops io-duration-198M 177.00 ( 0.00%) 21.00 ( 88.14%)
Ops io-duration-430M 168.00 ( 0.00%) 25.00 ( 85.12%)
Ops io-duration-661M 214.00 ( 0.00%) 30.00 ( 85.98%)
Ops io-duration-893M 186.00 ( 0.00%) 32.00 ( 82.80%)
Ops io-duration-1125M 175.00 ( 0.00%) 42.00 ( 76.00%)
Ops io-duration-1356M 245.00 ( 0.00%) 51.00 ( 79.18%)
Ops swaptotal-0M 487760.00 ( 0.00%) 459754.00 ( 5.74%)
Ops swaptotal-198M 563581.00 ( 0.00%) 485194.00 ( 13.91%)
Ops swaptotal-430M 579472.00 ( 0.00%) 500817.00 ( 13.57%)
Ops swaptotal-661M 568086.00 ( 0.00%) 524209.00 ( 7.72%)
Ops swaptotal-893M 584405.00 ( 0.00%) 509846.00 ( 12.76%)
Ops swaptotal-1125M 572992.00 ( 0.00%) 534115.00 ( 6.78%)
Ops swaptotal-1356M 573259.00 ( 0.00%) 529814.00 ( 7.58%)
Ops swapin-0M 231250.00 ( 0.00%) 236069.00 ( -2.08%)
Ops swapin-198M 312259.00 ( 0.00%) 239149.00 ( 23.41%)
Ops swapin-430M 327178.00 ( 0.00%) 246803.00 ( 24.57%)
Ops swapin-661M 319575.00 ( 0.00%) 273644.00 ( 14.37%)
Ops swapin-893M 328195.00 ( 0.00%) 257327.00 ( 21.59%)
Ops swapin-1125M 317345.00 ( 0.00%) 271109.00 ( 14.57%)
Ops swapin-1356M 312858.00 ( 0.00%) 266050.00 ( 14.96%)
Ops minorfaults-0M 592150.00 ( 0.00%) 646076.00 ( -9.11%)
Ops minorfaults-198M 637339.00 ( 0.00%) 676441.00 ( -6.14%)
Ops minorfaults-430M 626228.00 ( 0.00%) 684715.00 ( -9.34%)
Ops minorfaults-661M 625089.00 ( 0.00%) 670639.00 ( -7.29%)
Ops minorfaults-893M 612877.00 ( 0.00%) 669723.00 ( -9.28%)
Ops minorfaults-1125M 624800.00 ( 0.00%) 667025.00 ( -6.76%)
Ops minorfaults-1356M 618800.00 ( 0.00%) 657600.00 ( -6.27%)
Ops majorfaults-0M 67664.00 ( 0.00%) 40060.00 ( 40.80%)
Ops majorfaults-198M 72377.00 ( 0.00%) 39517.00 ( 45.40%)
Ops majorfaults-430M 71822.00 ( 0.00%) 38895.00 ( 45.85%)
Ops majorfaults-661M 70009.00 ( 0.00%) 39625.00 ( 43.40%)
Ops majorfaults-893M 74988.00 ( 0.00%) 38073.00 ( 49.23%)
Ops majorfaults-1125M 72458.00 ( 0.00%) 38206.00 ( 47.27%)
Ops majorfaults-1356M 70549.00 ( 0.00%) 37430.00 ( 46.94%)
Regards,
-Bob
On Mon, 17 Jun 2013 14:20:05 +0800 Bob Liu <[email protected]> wrote:
> Hi Seth,
>
> On Tue, Jun 4, 2013 at 4:33 AM, Seth Jennings
> <[email protected]> wrote:
> > zswap is a thin backend for frontswap that takes pages that are in the process
> > of being swapped out and attempts to compress them and store them in a
> > RAM-based memory pool. This can result in a significant I/O reduction on the
> > swap device and, in the case where decompressing from RAM is faster than
> > reading from the swap device, can also improve workload performance.
> >
> > It also has support for evicting swap pages that are currently compressed in
> > zswap to the swap device on an LRU(ish) basis. This functionality makes zswap a
> > true cache in that, once the cache is full, the oldest pages can be moved out
> > of zswap to the swap device so newer pages can be compressed and stored in
> > zswap.
> >
> > This patch adds the zswap driver to mm/
> >
>
> Do you have any more benchmark can share with me ? To figure out that
> we can benefit from zswap.
>
> I found zswap will cause performance drop when using mmtests-0.10 to test it.
> The config file I'm using is: config-global-dhp__parallelio-memcachetest
Thanks for testing.
> The result is:
> (v3.10-rc4-2G-nozswap was without zswap but the performance is better.)
>
> v3.10-rc4 v3.10-rc4
> 2G-zswap-base 2G-nozswap
> Ops memcachetest-0M 604.00 ( 0.00%) 1077.00 ( 78.31%)
> Ops memcachetest-198M 630.00 ( 0.00%) 1007.00 ( 59.84%)
> Ops memcachetest-430M 609.00 ( 0.00%) 939.00 ( 54.19%)
> Ops memcachetest-661M 604.00 ( 0.00%) 845.00 ( 39.90%)
> Ops memcachetest-893M 591.00 ( 0.00%) 839.00 ( 41.96%)
> Ops memcachetest-1125M 599.00 ( 0.00%) 781.00 ( 30.38%)
> Ops memcachetest-1356M 588.00 ( 0.00%) 771.00 ( 31.12%)
> Ops io-duration-0M 0.00 ( 0.00%) 1.00 (-99.00%)
> Ops io-duration-198M 177.00 ( 0.00%) 21.00 ( 88.14%)
> Ops io-duration-430M 168.00 ( 0.00%) 25.00 ( 85.12%)
> Ops io-duration-661M 214.00 ( 0.00%) 30.00 ( 85.98%)
> Ops io-duration-893M 186.00 ( 0.00%) 32.00 ( 82.80%)
> Ops io-duration-1125M 175.00 ( 0.00%) 42.00 ( 76.00%)
> Ops io-duration-1356M 245.00 ( 0.00%) 51.00 ( 79.18%)
> Ops swaptotal-0M 487760.00 ( 0.00%) 459754.00 ( 5.74%)
> Ops swaptotal-198M 563581.00 ( 0.00%) 485194.00 ( 13.91%)
> Ops swaptotal-430M 579472.00 ( 0.00%) 500817.00 ( 13.57%)
> Ops swaptotal-661M 568086.00 ( 0.00%) 524209.00 ( 7.72%)
> Ops swaptotal-893M 584405.00 ( 0.00%) 509846.00 ( 12.76%)
> Ops swaptotal-1125M 572992.00 ( 0.00%) 534115.00 ( 6.78%)
> Ops swaptotal-1356M 573259.00 ( 0.00%) 529814.00 ( 7.58%)
> Ops swapin-0M 231250.00 ( 0.00%) 236069.00 ( -2.08%)
> Ops swapin-198M 312259.00 ( 0.00%) 239149.00 ( 23.41%)
> Ops swapin-430M 327178.00 ( 0.00%) 246803.00 ( 24.57%)
> Ops swapin-661M 319575.00 ( 0.00%) 273644.00 ( 14.37%)
> Ops swapin-893M 328195.00 ( 0.00%) 257327.00 ( 21.59%)
> Ops swapin-1125M 317345.00 ( 0.00%) 271109.00 ( 14.57%)
> Ops swapin-1356M 312858.00 ( 0.00%) 266050.00 ( 14.96%)
> Ops minorfaults-0M 592150.00 ( 0.00%) 646076.00 ( -9.11%)
> Ops minorfaults-198M 637339.00 ( 0.00%) 676441.00 ( -6.14%)
> Ops minorfaults-430M 626228.00 ( 0.00%) 684715.00 ( -9.34%)
> Ops minorfaults-661M 625089.00 ( 0.00%) 670639.00 ( -7.29%)
> Ops minorfaults-893M 612877.00 ( 0.00%) 669723.00 ( -9.28%)
> Ops minorfaults-1125M 624800.00 ( 0.00%) 667025.00 ( -6.76%)
> Ops minorfaults-1356M 618800.00 ( 0.00%) 657600.00 ( -6.27%)
> Ops majorfaults-0M 67664.00 ( 0.00%) 40060.00 ( 40.80%)
> Ops majorfaults-198M 72377.00 ( 0.00%) 39517.00 ( 45.40%)
> Ops majorfaults-430M 71822.00 ( 0.00%) 38895.00 ( 45.85%)
> Ops majorfaults-661M 70009.00 ( 0.00%) 39625.00 ( 43.40%)
> Ops majorfaults-893M 74988.00 ( 0.00%) 38073.00 ( 49.23%)
> Ops majorfaults-1125M 72458.00 ( 0.00%) 38206.00 ( 47.27%)
> Ops majorfaults-1356M 70549.00 ( 0.00%) 37430.00 ( 46.94%)
So the minor fault rate improved and everything else got worse?
I'm not sure how representative this is of real workloads, but it does
look rather fatal for zswap. The differences are so large, I wonder if
it's just some silly bug or config issue.
>
> So the minor fault rate improved and everything else got worse?
I did the test again, in a new clean environment.
I'm sure the config files are the same except enabled zswap.
v3.10-rc4 v3.10-rc4
2G-parallio-zswapbas 2G-parallio-nozswap
Ops memcachetest-0M 819.00 ( 0.00%) 1041.00 ( 27.11%)
Ops memcachetest-198M 736.00 ( 0.00%) 973.00 ( 32.20%)
Ops memcachetest-430M 700.00 ( 0.00%) 892.00 ( 27.43%)
Ops memcachetest-661M 672.00 ( 0.00%) 819.00 ( 21.88%)
Ops memcachetest-893M 675.00 ( 0.00%) 775.00 ( 14.81%)
Ops memcachetest-1125M 665.00 ( 0.00%) 764.00 ( 14.89%)
Ops memcachetest-1356M 641.00 ( 0.00%) 749.00 ( 16.85%)
Ops io-duration-0M 0.00 ( 0.00%) 0.00 ( 0.00%)
Ops io-duration-198M 111.00 ( 0.00%) 21.00 ( 81.08%)
Ops io-duration-430M 125.00 ( 0.00%) 29.00 ( 76.80%)
Ops io-duration-661M 153.00 ( 0.00%) 34.00 ( 77.78%)
Ops io-duration-893M 118.00 ( 0.00%) 36.00 ( 69.49%)
Ops io-duration-1125M 142.00 ( 0.00%) 43.00 ( 69.72%)
Ops io-duration-1356M 156.00 ( 0.00%) 50.00 ( 67.95%)
Ops swaptotal-0M 462237.00 ( 0.00%) 469193.00 ( -1.50%)
Ops swaptotal-198M 490462.00 ( 0.00%) 496201.00 ( -1.17%)
Ops swaptotal-430M 500469.00 ( 0.00%) 520400.00 ( -3.98%)
Ops swaptotal-661M 506038.00 ( 0.00%) 538872.00 ( -6.49%)
Ops swaptotal-893M 514930.00 ( 0.00%) 522590.00 ( -1.49%)
Ops swaptotal-1125M 521010.00 ( 0.00%) 526934.00 ( -1.14%)
Ops swaptotal-1356M 513128.00 ( 0.00%) 525241.00 ( -2.36%)
Ops swapin-0M 246425.00 ( 0.00%) 251226.00 ( -1.95%)
Ops swapin-198M 266446.00 ( 0.00%) 236126.00 ( 11.38%)
Ops swapin-430M 271586.00 ( 0.00%) 265193.00 ( 2.35%)
Ops swapin-661M 263404.00 ( 0.00%) 280281.00 ( -6.41%)
Ops swapin-893M 263958.00 ( 0.00%) 263004.00 ( 0.36%)
Ops swapin-1125M 276149.00 ( 0.00%) 261962.00 ( 5.14%)
Ops swapin-1356M 264214.00 ( 0.00%) 262571.00 ( 0.62%)
Ops minorfaults-0M 629965.00 ( 0.00%) 625759.00 ( 0.67%)
Ops minorfaults-198M 641320.00 ( 0.00%) 769752.00 (-20.03%)
Ops minorfaults-430M 635270.00 ( 0.00%) 678590.00 ( -6.82%)
Ops minorfaults-661M 625123.00 ( 0.00%) 669308.00 ( -7.07%)
Ops minorfaults-893M 625165.00 ( 0.00%) 656343.00 ( -4.99%)
Ops minorfaults-1125M 624358.00 ( 0.00%) 657954.00 ( -5.38%)
Ops minorfaults-1356M 619724.00 ( 0.00%) 672035.00 ( -8.44%)
Ops majorfaults-0M 57664.00 ( 0.00%) 39395.00 ( 31.68%)
Ops majorfaults-198M 59747.00 ( 0.00%) 38758.00 ( 35.13%)
Ops majorfaults-430M 63453.00 ( 0.00%) 39819.00 ( 37.25%)
Ops majorfaults-661M 61310.00 ( 0.00%) 40171.00 ( 34.48%)
Ops majorfaults-893M 62544.00 ( 0.00%) 37576.00 ( 39.92%)
Ops majorfaults-1125M 60866.00 ( 0.00%) 36891.00 ( 39.39%)
Ops majorfaults-1356M 66598.00 ( 0.00%) 37123.00 ( 44.26%)
It shows clearly that swaptotal and minorfaults get improved a little
if enabled zswap.
But with the cost that the performance of everything else dropped a lot.
--
Regards,
--Bob
>
> I'm not sure how representative this is of real workloads, but it does
> look rather fatal for zswap. The differences are so large, I wonder if
> it's just some silly bug or config issue.
>
In my observation, zswap_pool_pages always close to zswap_stored_pages
in this testing.
I think it means that the fragmentation of zswap is heavy.
Since in idea state number of zswap pool pages should be half of stored pages.
The reason may be this workload is not suitable for compression.
The data of it can't be compressed to a low percent.
It can only compressed to around 70% percent(not exactly but at least
above 50%).
I made a simple patch to limit the fragment of zswap to 70%.
The result can be better but still not positive.
v3.10-rc4 v3.10-rc4
2G-parallio-nozswap 2G-parallio-zswapdefrag
Ops memcachetest-0M 1041.00 ( 0.00%) 1058.00 ( 1.63%)
Ops memcachetest-198M 973.00 ( 0.00%) 1019.00 ( 4.73%)
Ops memcachetest-430M 892.00 ( 0.00%) 831.00 ( -6.84%)
Ops memcachetest-661M 819.00 ( 0.00%) 850.00 ( 3.79%)
Ops memcachetest-893M 775.00 ( 0.00%) 784.00 ( 1.16%)
Ops memcachetest-1125M 764.00 ( 0.00%) 766.00 ( 0.26%)
Ops memcachetest-1356M 749.00 ( 0.00%) 782.00 ( 4.41%)
Ops io-duration-0M 0.00 ( 0.00%) 0.00 ( 0.00%)
Ops io-duration-198M 21.00 ( 0.00%) 28.00 (-33.33%)
Ops io-duration-430M 29.00 ( 0.00%) 32.00 (-10.34%)
Ops io-duration-661M 34.00 ( 0.00%) 34.00 ( 0.00%)
Ops io-duration-893M 36.00 ( 0.00%) 42.00 (-16.67%)
Ops io-duration-1125M 43.00 ( 0.00%) 47.00 ( -9.30%)
Ops io-duration-1356M 50.00 ( 0.00%) 49.00 ( 2.00%)
Ops swaptotal-0M 469193.00 ( 0.00%) 461146.00 ( 1.72%)
Ops swaptotal-198M 496201.00 ( 0.00%) 495692.00 ( 0.10%)
Ops swaptotal-430M 520400.00 ( 0.00%) 520252.00 ( 0.03%)
Ops swaptotal-661M 538872.00 ( 0.00%) 513541.00 ( 4.70%)
Ops swaptotal-893M 522590.00 ( 0.00%) 532311.00 ( -1.86%)
Ops swaptotal-1125M 526934.00 ( 0.00%) 527089.00 ( -0.03%)
Ops swaptotal-1356M 525241.00 ( 0.00%) 525747.00 ( -0.10%)
Ops swapin-0M 251226.00 ( 0.00%) 248426.00 ( 1.11%)
Ops swapin-198M 236126.00 ( 0.00%) 239031.00 ( -1.23%)
Ops swapin-430M 265193.00 ( 0.00%) 266174.00 ( -0.37%)
Ops swapin-661M 280281.00 ( 0.00%) 263151.00 ( 6.11%)
Ops swapin-893M 263004.00 ( 0.00%) 268473.00 ( -2.08%)
Ops swapin-1125M 261962.00 ( 0.00%) 264925.00 ( -1.13%)
Ops swapin-1356M 262571.00 ( 0.00%) 266695.00 ( -1.57%)
Ops minorfaults-0M 625759.00 ( 0.00%) 620448.00 ( 0.85%)
Ops minorfaults-198M 769752.00 ( 0.00%) 703458.00 ( 8.61%)
Ops minorfaults-430M 678590.00 ( 0.00%) 686257.00 ( -1.13%)
Ops minorfaults-661M 669308.00 ( 0.00%) 668845.00 ( 0.07%)
Ops minorfaults-893M 656343.00 ( 0.00%) 680286.00 ( -3.65%)
Ops minorfaults-1125M 657954.00 ( 0.00%) 655280.00 ( 0.41%)
Ops minorfaults-1356M 672035.00 ( 0.00%) 659861.00 ( 1.81%)
Ops majorfaults-0M 39395.00 ( 0.00%) 38828.00 ( 1.44%)
Ops majorfaults-198M 38758.00 ( 0.00%) 42876.00 (-10.62%)
Ops majorfaults-430M 39819.00 ( 0.00%) 38668.00 ( 2.89%)
Ops majorfaults-661M 40171.00 ( 0.00%) 38443.00 ( 4.30%)
Ops majorfaults-893M 37576.00 ( 0.00%) 37664.00 ( -0.23%)
Ops majorfaults-1125M 36891.00 ( 0.00%) 37527.00 ( -1.72%)
Ops majorfaults-1356M 37123.00 ( 0.00%) 37779.00 ( -1.77%)
--
Regards,
--Bob
On Mon, Jun 17, 2013 at 02:20:05PM +0800, Bob Liu wrote:
> Hi Seth,
>
> On Tue, Jun 4, 2013 at 4:33 AM, Seth Jennings
> <[email protected]> wrote:
> > zswap is a thin backend for frontswap that takes pages that are in the process
> > of being swapped out and attempts to compress them and store them in a
> > RAM-based memory pool. This can result in a significant I/O reduction on the
> > swap device and, in the case where decompressing from RAM is faster than
> > reading from the swap device, can also improve workload performance.
> >
> > It also has support for evicting swap pages that are currently compressed in
> > zswap to the swap device on an LRU(ish) basis. This functionality makes zswap a
> > true cache in that, once the cache is full, the oldest pages can be moved out
> > of zswap to the swap device so newer pages can be compressed and stored in
> > zswap.
> >
> > This patch adds the zswap driver to mm/
> >
>
> Do you have any more benchmark can share with me ? To figure out that
> we can benefit from zswap.
The two I've done or kernbench and SPECjbb. I'm trying out the memtests
now. I'd like to be able to explain the numbers you are seeing at least.
Sorry for the delay. I'll get back to you once I've figured out how
to using mmtests and get some results/explanations.
Also, how much physical RAM did this box have? I see 2G in the profile name
but not sure if that is the workload size or the RAM size. I seems that the
test is overcommitted from the beginning as indicated by the swap activity.
I know that the parallelio-memcachetest default profile only uses 80% of
physical memory, so you have apparently made a change yes?
Seth
>
> I found zswap will cause performance drop when using mmtests-0.10 to test it.
> The config file I'm using is: config-global-dhp__parallelio-memcachetest
>
> The result is:
> (v3.10-rc4-2G-nozswap was without zswap but the performance is better.)
>
> v3.10-rc4 v3.10-rc4
> 2G-zswap-base 2G-nozswap
> Ops memcachetest-0M 604.00 ( 0.00%) 1077.00 ( 78.31%)
> Ops memcachetest-198M 630.00 ( 0.00%) 1007.00 ( 59.84%)
> Ops memcachetest-430M 609.00 ( 0.00%) 939.00 ( 54.19%)
> Ops memcachetest-661M 604.00 ( 0.00%) 845.00 ( 39.90%)
> Ops memcachetest-893M 591.00 ( 0.00%) 839.00 ( 41.96%)
> Ops memcachetest-1125M 599.00 ( 0.00%) 781.00 ( 30.38%)
> Ops memcachetest-1356M 588.00 ( 0.00%) 771.00 ( 31.12%)
> Ops io-duration-0M 0.00 ( 0.00%) 1.00 (-99.00%)
> Ops io-duration-198M 177.00 ( 0.00%) 21.00 ( 88.14%)
> Ops io-duration-430M 168.00 ( 0.00%) 25.00 ( 85.12%)
> Ops io-duration-661M 214.00 ( 0.00%) 30.00 ( 85.98%)
> Ops io-duration-893M 186.00 ( 0.00%) 32.00 ( 82.80%)
> Ops io-duration-1125M 175.00 ( 0.00%) 42.00 ( 76.00%)
> Ops io-duration-1356M 245.00 ( 0.00%) 51.00 ( 79.18%)
> Ops swaptotal-0M 487760.00 ( 0.00%) 459754.00 ( 5.74%)
> Ops swaptotal-198M 563581.00 ( 0.00%) 485194.00 ( 13.91%)
> Ops swaptotal-430M 579472.00 ( 0.00%) 500817.00 ( 13.57%)
> Ops swaptotal-661M 568086.00 ( 0.00%) 524209.00 ( 7.72%)
> Ops swaptotal-893M 584405.00 ( 0.00%) 509846.00 ( 12.76%)
> Ops swaptotal-1125M 572992.00 ( 0.00%) 534115.00 ( 6.78%)
> Ops swaptotal-1356M 573259.00 ( 0.00%) 529814.00 ( 7.58%)
> Ops swapin-0M 231250.00 ( 0.00%) 236069.00 ( -2.08%)
> Ops swapin-198M 312259.00 ( 0.00%) 239149.00 ( 23.41%)
> Ops swapin-430M 327178.00 ( 0.00%) 246803.00 ( 24.57%)
> Ops swapin-661M 319575.00 ( 0.00%) 273644.00 ( 14.37%)
> Ops swapin-893M 328195.00 ( 0.00%) 257327.00 ( 21.59%)
> Ops swapin-1125M 317345.00 ( 0.00%) 271109.00 ( 14.57%)
> Ops swapin-1356M 312858.00 ( 0.00%) 266050.00 ( 14.96%)
> Ops minorfaults-0M 592150.00 ( 0.00%) 646076.00 ( -9.11%)
> Ops minorfaults-198M 637339.00 ( 0.00%) 676441.00 ( -6.14%)
> Ops minorfaults-430M 626228.00 ( 0.00%) 684715.00 ( -9.34%)
> Ops minorfaults-661M 625089.00 ( 0.00%) 670639.00 ( -7.29%)
> Ops minorfaults-893M 612877.00 ( 0.00%) 669723.00 ( -9.28%)
> Ops minorfaults-1125M 624800.00 ( 0.00%) 667025.00 ( -6.76%)
> Ops minorfaults-1356M 618800.00 ( 0.00%) 657600.00 ( -6.27%)
> Ops majorfaults-0M 67664.00 ( 0.00%) 40060.00 ( 40.80%)
> Ops majorfaults-198M 72377.00 ( 0.00%) 39517.00 ( 45.40%)
> Ops majorfaults-430M 71822.00 ( 0.00%) 38895.00 ( 45.85%)
> Ops majorfaults-661M 70009.00 ( 0.00%) 39625.00 ( 43.40%)
> Ops majorfaults-893M 74988.00 ( 0.00%) 38073.00 ( 49.23%)
> Ops majorfaults-1125M 72458.00 ( 0.00%) 38206.00 ( 47.27%)
> Ops majorfaults-1356M 70549.00 ( 0.00%) 37430.00 ( 46.94%)
>
> Regards,
> -Bob
On Wed, Jun 19, 2013 at 10:09 PM, Seth Jennings
<[email protected]> wrote:
> On Mon, Jun 17, 2013 at 02:20:05PM +0800, Bob Liu wrote:
>> Hi Seth,
>>
>> On Tue, Jun 4, 2013 at 4:33 AM, Seth Jennings
>> <[email protected]> wrote:
>> > zswap is a thin backend for frontswap that takes pages that are in the process
>> > of being swapped out and attempts to compress them and store them in a
>> > RAM-based memory pool. This can result in a significant I/O reduction on the
>> > swap device and, in the case where decompressing from RAM is faster than
>> > reading from the swap device, can also improve workload performance.
>> >
>> > It also has support for evicting swap pages that are currently compressed in
>> > zswap to the swap device on an LRU(ish) basis. This functionality makes zswap a
>> > true cache in that, once the cache is full, the oldest pages can be moved out
>> > of zswap to the swap device so newer pages can be compressed and stored in
>> > zswap.
>> >
>> > This patch adds the zswap driver to mm/
>> >
>>
>> Do you have any more benchmark can share with me ? To figure out that
>> we can benefit from zswap.
>
> The two I've done or kernbench and SPECjbb. I'm trying out the memtests
Thanks, I'll try to setup them.
> now. I'd like to be able to explain the numbers you are seeing at least.
>
> Sorry for the delay. I'll get back to you once I've figured out how
> to using mmtests and get some results/explanations.
>
> Also, how much physical RAM did this box have? I see 2G in the profile name
> but not sure if that is the workload size or the RAM size. I seems that the
2G RAM size.
> test is overcommitted from the beginning as indicated by the swap activity.
> I know that the parallelio-memcachetest default profile only uses 80% of
> physical memory, so you have apparently made a change yes?
>
No, I just "cp configs/config-global-dhp__parallelio-memcachetest
config" and then run mmtests.sh with monitor.
I'm using mmtests version 0.10.
--
Regards,
--Bob
On Mon, Jun 17, 2013 at 02:20:05PM +0800, Bob Liu wrote:
> Hi Seth,
>
> On Tue, Jun 4, 2013 at 4:33 AM, Seth Jennings
> <[email protected]> wrote:
> > zswap is a thin backend for frontswap that takes pages that are in the process
> > of being swapped out and attempts to compress them and store them in a
> > RAM-based memory pool. This can result in a significant I/O reduction on the
> > swap device and, in the case where decompressing from RAM is faster than
> > reading from the swap device, can also improve workload performance.
> >
> > It also has support for evicting swap pages that are currently compressed in
> > zswap to the swap device on an LRU(ish) basis. This functionality makes zswap a
> > true cache in that, once the cache is full, the oldest pages can be moved out
> > of zswap to the swap device so newer pages can be compressed and stored in
> > zswap.
> >
> > This patch adds the zswap driver to mm/
> >
>
> Do you have any more benchmark can share with me ? To figure out that
> we can benefit from zswap.
>
> I found zswap will cause performance drop when using mmtests-0.10 to test it.
> The config file I'm using is: config-global-dhp__parallelio-memcachetest
>
> The result is:
> (v3.10-rc4-2G-nozswap was without zswap but the performance is better.)
>
> v3.10-rc4 v3.10-rc4
> 2G-zswap-base 2G-nozswap
> Ops memcachetest-0M 604.00 ( 0.00%) 1077.00 ( 78.31%)
> Ops memcachetest-198M 630.00 ( 0.00%) 1007.00 ( 59.84%)
> Ops memcachetest-430M 609.00 ( 0.00%) 939.00 ( 54.19%)
> Ops memcachetest-661M 604.00 ( 0.00%) 845.00 ( 39.90%)
> Ops memcachetest-893M 591.00 ( 0.00%) 839.00 ( 41.96%)
> Ops memcachetest-1125M 599.00 ( 0.00%) 781.00 ( 30.38%)
> Ops memcachetest-1356M 588.00 ( 0.00%) 771.00 ( 31.12%)
> Ops io-duration-0M 0.00 ( 0.00%) 1.00 (-99.00%)
> Ops io-duration-198M 177.00 ( 0.00%) 21.00 ( 88.14%)
> Ops io-duration-430M 168.00 ( 0.00%) 25.00 ( 85.12%)
> Ops io-duration-661M 214.00 ( 0.00%) 30.00 ( 85.98%)
> Ops io-duration-893M 186.00 ( 0.00%) 32.00 ( 82.80%)
> Ops io-duration-1125M 175.00 ( 0.00%) 42.00 ( 76.00%)
> Ops io-duration-1356M 245.00 ( 0.00%) 51.00 ( 79.18%)
> Ops swaptotal-0M 487760.00 ( 0.00%) 459754.00 ( 5.74%)
> Ops swaptotal-198M 563581.00 ( 0.00%) 485194.00 ( 13.91%)
> Ops swaptotal-430M 579472.00 ( 0.00%) 500817.00 ( 13.57%)
> Ops swaptotal-661M 568086.00 ( 0.00%) 524209.00 ( 7.72%)
> Ops swaptotal-893M 584405.00 ( 0.00%) 509846.00 ( 12.76%)
> Ops swaptotal-1125M 572992.00 ( 0.00%) 534115.00 ( 6.78%)
> Ops swaptotal-1356M 573259.00 ( 0.00%) 529814.00 ( 7.58%)
> Ops swapin-0M 231250.00 ( 0.00%) 236069.00 ( -2.08%)
> Ops swapin-198M 312259.00 ( 0.00%) 239149.00 ( 23.41%)
> Ops swapin-430M 327178.00 ( 0.00%) 246803.00 ( 24.57%)
> Ops swapin-661M 319575.00 ( 0.00%) 273644.00 ( 14.37%)
> Ops swapin-893M 328195.00 ( 0.00%) 257327.00 ( 21.59%)
> Ops swapin-1125M 317345.00 ( 0.00%) 271109.00 ( 14.57%)
> Ops swapin-1356M 312858.00 ( 0.00%) 266050.00 ( 14.96%)
> Ops minorfaults-0M 592150.00 ( 0.00%) 646076.00 ( -9.11%)
> Ops minorfaults-198M 637339.00 ( 0.00%) 676441.00 ( -6.14%)
> Ops minorfaults-430M 626228.00 ( 0.00%) 684715.00 ( -9.34%)
> Ops minorfaults-661M 625089.00 ( 0.00%) 670639.00 ( -7.29%)
> Ops minorfaults-893M 612877.00 ( 0.00%) 669723.00 ( -9.28%)
> Ops minorfaults-1125M 624800.00 ( 0.00%) 667025.00 ( -6.76%)
> Ops minorfaults-1356M 618800.00 ( 0.00%) 657600.00 ( -6.27%)
> Ops majorfaults-0M 67664.00 ( 0.00%) 40060.00 ( 40.80%)
> Ops majorfaults-198M 72377.00 ( 0.00%) 39517.00 ( 45.40%)
> Ops majorfaults-430M 71822.00 ( 0.00%) 38895.00 ( 45.85%)
> Ops majorfaults-661M 70009.00 ( 0.00%) 39625.00 ( 43.40%)
> Ops majorfaults-893M 74988.00 ( 0.00%) 38073.00 ( 49.23%)
> Ops majorfaults-1125M 72458.00 ( 0.00%) 38206.00 ( 47.27%)
> Ops majorfaults-1356M 70549.00 ( 0.00%) 37430.00 ( 46.94%)
Just made a mmtests run of my own and got very different results:
parallelio-memcachetest
v3.10-rc6 v3.10-rc6
base zswap
Ops memcachetest-0M 7815.00 ( 0.00%) 7843.00 ( 0.36%)
Ops memcachetest-596M 12116.00 ( 0.00%) 12158.00 ( 0.35%)
Ops memcachetest-1989M 2226.00 ( 0.00%) 5314.00 (138.72%)
Ops memcachetest-3382M 1910.00 ( 0.00%) 4427.00 (131.78%)
Ops io-duration-0M 0.00 ( 0.00%) 0.00 ( 0.00%)
Ops io-duration-596M 18.00 ( 0.00%) 12.00 ( 33.33%)
Ops io-duration-1989M 82.00 ( 0.00%) 57.00 ( 30.49%)
Ops io-duration-3382M 91.00 ( 0.00%) 94.00 ( -3.30%)
Ops swaptotal-0M 0.00 ( 0.00%) 0.00 ( 0.00%)
Ops swaptotal-596M 0.00 ( 0.00%) 0.00 ( 0.00%)
Ops swaptotal-1989M 305182.00 ( 0.00%) 91508.00 ( 70.02%)
Ops swaptotal-3382M 353389.00 ( 0.00%) 74932.00 ( 78.80%)
Ops swapin-0M 0.00 ( 0.00%) 0.00 ( 0.00%)
Ops swapin-596M 0.00 ( 0.00%) 0.00 ( 0.00%)
Ops swapin-1989M 131071.00 ( 0.00%) 45657.00 ( 65.17%)
Ops swapin-3382M 135003.00 ( 0.00%) 37245.00 ( 72.41%)
Ops minorfaults-0M 1201113.00 ( 0.00%) 1201229.00 ( -0.01%)
Ops minorfaults-596M 1218437.00 ( 0.00%) 1218824.00 ( -0.03%)
Ops minorfaults-1989M 1260652.00 ( 0.00%) 1270762.00 ( -0.80%)
Ops minorfaults-3382M 1251389.00 ( 0.00%) 1248756.00 ( 0.21%)
Ops majorfaults-0M 0.00 ( 0.00%) 0.00 ( 0.00%)
Ops majorfaults-596M 34.00 ( 0.00%) 0.00 ( 0.00%)
Ops majorfaults-1989M 16561.00 ( 0.00%) 7789.00 ( 52.97%)
Ops majorfaults-3382M 17031.00 ( 0.00%) 6372.00 ( 62.59%)
Basically the results show that once swapping starts (which happens even in the
0MB case in your results which is puzzling), zswap reduces swapins by around
70% (and as a result swaptotal and majorfaults) and increases memcached
throughput by over 130% compared to the normal swapping case w/o zswap.
This test illustrates a great use case for zswap. The test is really designed
to detect suboptimal page reclaim decisions. Ideally the memcached pages would
never reach the end of the inactive LRU and be swapped out. However, since
there is a lot of I/O going on, if a memcached page does get put on the
inactive list, it can quickly move to the end. In this case, zswap catches the
page and memcached has a chance to fault it back in from the compressed cache
before actual swapping to disk occurs.
Seth
On Thu, Jun 20, 2013 at 10:37 AM, Seth Jennings
<[email protected]> wrote:
> On Mon, Jun 17, 2013 at 02:20:05PM +0800, Bob Liu wrote:
>> Hi Seth,
>>
>> On Tue, Jun 4, 2013 at 4:33 AM, Seth Jennings
>> <[email protected]> wrote:
>> > zswap is a thin backend for frontswap that takes pages that are in the process
>> > of being swapped out and attempts to compress them and store them in a
>> > RAM-based memory pool. This can result in a significant I/O reduction on the
>> > swap device and, in the case where decompressing from RAM is faster than
>> > reading from the swap device, can also improve workload performance.
>> >
>> > It also has support for evicting swap pages that are currently compressed in
>> > zswap to the swap device on an LRU(ish) basis. This functionality makes zswap a
>> > true cache in that, once the cache is full, the oldest pages can be moved out
>> > of zswap to the swap device so newer pages can be compressed and stored in
>> > zswap.
>> >
>> > This patch adds the zswap driver to mm/
>> >
>>
>> Do you have any more benchmark can share with me ? To figure out that
>> we can benefit from zswap.
>>
>> I found zswap will cause performance drop when using mmtests-0.10 to test it.
>> The config file I'm using is: config-global-dhp__parallelio-memcachetest
>>
>> The result is:
>> (v3.10-rc4-2G-nozswap was without zswap but the performance is better.)
>>
>> v3.10-rc4 v3.10-rc4
>> 2G-zswap-base 2G-nozswap
>> Ops memcachetest-0M 604.00 ( 0.00%) 1077.00 ( 78.31%)
>> Ops memcachetest-198M 630.00 ( 0.00%) 1007.00 ( 59.84%)
>> Ops memcachetest-430M 609.00 ( 0.00%) 939.00 ( 54.19%)
>> Ops memcachetest-661M 604.00 ( 0.00%) 845.00 ( 39.90%)
>> Ops memcachetest-893M 591.00 ( 0.00%) 839.00 ( 41.96%)
>> Ops memcachetest-1125M 599.00 ( 0.00%) 781.00 ( 30.38%)
>> Ops memcachetest-1356M 588.00 ( 0.00%) 771.00 ( 31.12%)
>> Ops io-duration-0M 0.00 ( 0.00%) 1.00 (-99.00%)
>> Ops io-duration-198M 177.00 ( 0.00%) 21.00 ( 88.14%)
>> Ops io-duration-430M 168.00 ( 0.00%) 25.00 ( 85.12%)
>> Ops io-duration-661M 214.00 ( 0.00%) 30.00 ( 85.98%)
>> Ops io-duration-893M 186.00 ( 0.00%) 32.00 ( 82.80%)
>> Ops io-duration-1125M 175.00 ( 0.00%) 42.00 ( 76.00%)
>> Ops io-duration-1356M 245.00 ( 0.00%) 51.00 ( 79.18%)
>> Ops swaptotal-0M 487760.00 ( 0.00%) 459754.00 ( 5.74%)
>> Ops swaptotal-198M 563581.00 ( 0.00%) 485194.00 ( 13.91%)
>> Ops swaptotal-430M 579472.00 ( 0.00%) 500817.00 ( 13.57%)
>> Ops swaptotal-661M 568086.00 ( 0.00%) 524209.00 ( 7.72%)
>> Ops swaptotal-893M 584405.00 ( 0.00%) 509846.00 ( 12.76%)
>> Ops swaptotal-1125M 572992.00 ( 0.00%) 534115.00 ( 6.78%)
>> Ops swaptotal-1356M 573259.00 ( 0.00%) 529814.00 ( 7.58%)
>> Ops swapin-0M 231250.00 ( 0.00%) 236069.00 ( -2.08%)
>> Ops swapin-198M 312259.00 ( 0.00%) 239149.00 ( 23.41%)
>> Ops swapin-430M 327178.00 ( 0.00%) 246803.00 ( 24.57%)
>> Ops swapin-661M 319575.00 ( 0.00%) 273644.00 ( 14.37%)
>> Ops swapin-893M 328195.00 ( 0.00%) 257327.00 ( 21.59%)
>> Ops swapin-1125M 317345.00 ( 0.00%) 271109.00 ( 14.57%)
>> Ops swapin-1356M 312858.00 ( 0.00%) 266050.00 ( 14.96%)
>> Ops minorfaults-0M 592150.00 ( 0.00%) 646076.00 ( -9.11%)
>> Ops minorfaults-198M 637339.00 ( 0.00%) 676441.00 ( -6.14%)
>> Ops minorfaults-430M 626228.00 ( 0.00%) 684715.00 ( -9.34%)
>> Ops minorfaults-661M 625089.00 ( 0.00%) 670639.00 ( -7.29%)
>> Ops minorfaults-893M 612877.00 ( 0.00%) 669723.00 ( -9.28%)
>> Ops minorfaults-1125M 624800.00 ( 0.00%) 667025.00 ( -6.76%)
>> Ops minorfaults-1356M 618800.00 ( 0.00%) 657600.00 ( -6.27%)
>> Ops majorfaults-0M 67664.00 ( 0.00%) 40060.00 ( 40.80%)
>> Ops majorfaults-198M 72377.00 ( 0.00%) 39517.00 ( 45.40%)
>> Ops majorfaults-430M 71822.00 ( 0.00%) 38895.00 ( 45.85%)
>> Ops majorfaults-661M 70009.00 ( 0.00%) 39625.00 ( 43.40%)
>> Ops majorfaults-893M 74988.00 ( 0.00%) 38073.00 ( 49.23%)
>> Ops majorfaults-1125M 72458.00 ( 0.00%) 38206.00 ( 47.27%)
>> Ops majorfaults-1356M 70549.00 ( 0.00%) 37430.00 ( 46.94%)
>
> Just made a mmtests run of my own and got very different results:
>
It's strange, I'll update to rc6 and try again.
By the way, are you using 824 hardware compressor instead of lzo?
> parallelio-memcachetest
> v3.10-rc6 v3.10-rc6
> base zswap
> Ops memcachetest-0M 7815.00 ( 0.00%) 7843.00 ( 0.36%)
> Ops memcachetest-596M 12116.00 ( 0.00%) 12158.00 ( 0.35%)
> Ops memcachetest-1989M 2226.00 ( 0.00%) 5314.00 (138.72%)
> Ops memcachetest-3382M 1910.00 ( 0.00%) 4427.00 (131.78%)
> Ops io-duration-0M 0.00 ( 0.00%) 0.00 ( 0.00%)
> Ops io-duration-596M 18.00 ( 0.00%) 12.00 ( 33.33%)
> Ops io-duration-1989M 82.00 ( 0.00%) 57.00 ( 30.49%)
> Ops io-duration-3382M 91.00 ( 0.00%) 94.00 ( -3.30%)
> Ops swaptotal-0M 0.00 ( 0.00%) 0.00 ( 0.00%)
> Ops swaptotal-596M 0.00 ( 0.00%) 0.00 ( 0.00%)
> Ops swaptotal-1989M 305182.00 ( 0.00%) 91508.00 ( 70.02%)
> Ops swaptotal-3382M 353389.00 ( 0.00%) 74932.00 ( 78.80%)
> Ops swapin-0M 0.00 ( 0.00%) 0.00 ( 0.00%)
> Ops swapin-596M 0.00 ( 0.00%) 0.00 ( 0.00%)
> Ops swapin-1989M 131071.00 ( 0.00%) 45657.00 ( 65.17%)
> Ops swapin-3382M 135003.00 ( 0.00%) 37245.00 ( 72.41%)
> Ops minorfaults-0M 1201113.00 ( 0.00%) 1201229.00 ( -0.01%)
> Ops minorfaults-596M 1218437.00 ( 0.00%) 1218824.00 ( -0.03%)
> Ops minorfaults-1989M 1260652.00 ( 0.00%) 1270762.00 ( -0.80%)
> Ops minorfaults-3382M 1251389.00 ( 0.00%) 1248756.00 ( 0.21%)
> Ops majorfaults-0M 0.00 ( 0.00%) 0.00 ( 0.00%)
> Ops majorfaults-596M 34.00 ( 0.00%) 0.00 ( 0.00%)
> Ops majorfaults-1989M 16561.00 ( 0.00%) 7789.00 ( 52.97%)
> Ops majorfaults-3382M 17031.00 ( 0.00%) 6372.00 ( 62.59%)
>
> Basically the results show that once swapping starts (which happens even in the
> 0MB case in your results which is puzzling), zswap reduces swapins by around
> 70% (and as a result swaptotal and majorfaults) and increases memcached
> throughput by over 130% compared to the normal swapping case w/o zswap.
>
> This test illustrates a great use case for zswap. The test is really designed
> to detect suboptimal page reclaim decisions. Ideally the memcached pages would
> never reach the end of the inactive LRU and be swapped out. However, since
> there is a lot of I/O going on, if a memcached page does get put on the
> inactive list, it can quickly move to the end. In this case, zswap catches the
> page and memcached has a chance to fault it back in from the compressed cache
> before actual swapping to disk occurs.
>
> Seth
>
--
Regards,
--Bob
On Thu, Jun 20, 2013 at 05:42:04PM +0800, Bob Liu wrote:
> > Just made a mmtests run of my own and got very different results:
> >
>
> It's strange, I'll update to rc6 and try again.
> By the way, are you using 824 hardware compressor instead of lzo?
My results where using lzo software compression.
Seth
On Thu, Jun 20, 2013 at 10:23 PM, Seth Jennings
<[email protected]> wrote:
> On Thu, Jun 20, 2013 at 05:42:04PM +0800, Bob Liu wrote:
>> > Just made a mmtests run of my own and got very different results:
>> >
>>
>> It's strange, I'll update to rc6 and try again.
>> By the way, are you using 824 hardware compressor instead of lzo?
>
> My results where using lzo software compression.
>
Thanks, and today I used another machine to test zswap.
The total ram size of that machine is around 4G.
This time the result is better:
rc6 rc6
zswap base
Ops memcachetest-0M 14619.00 ( 0.00%) 15602.00 ( 6.72%)
Ops memcachetest-435M 14727.00 ( 0.00%) 15860.00 ( 7.69%)
Ops memcachetest-944M 12452.00 ( 0.00%) 11812.00 ( -5.14%)
Ops memcachetest-1452M 12183.00 ( 0.00%) 9829.00 (-19.32%)
Ops memcachetest-1961M 11953.00 ( 0.00%) 9337.00 (-21.89%)
Ops memcachetest-2469M 11201.00 ( 0.00%) 7509.00 (-32.96%)
Ops memcachetest-2978M 9738.00 ( 0.00%) 5981.00 (-38.58%)
Ops io-duration-0M 0.00 ( 0.00%) 0.00 ( 0.00%)
Ops io-duration-435M 10.00 ( 0.00%) 6.00 ( 40.00%)
Ops io-duration-944M 19.00 ( 0.00%) 19.00 ( 0.00%)
Ops io-duration-1452M 31.00 ( 0.00%) 26.00 ( 16.13%)
Ops io-duration-1961M 40.00 ( 0.00%) 35.00 ( 12.50%)
Ops io-duration-2469M 45.00 ( 0.00%) 43.00 ( 4.44%)
Ops io-duration-2978M 58.00 ( 0.00%) 53.00 ( 8.62%)
Ops swaptotal-0M 56711.00 ( 0.00%) 8.00 ( 99.99%)
Ops swaptotal-435M 19218.00 ( 0.00%) 2101.00 ( 89.07%)
Ops swaptotal-944M 53233.00 ( 0.00%) 98055.00 (-84.20%)
Ops swaptotal-1452M 52064.00 ( 0.00%) 145624.00 (-179.70%)
Ops swaptotal-1961M 54960.00 ( 0.00%) 153907.00 (-180.03%)
Ops swaptotal-2469M 57485.00 ( 0.00%) 176340.00 (-206.76%)
Ops swaptotal-2978M 77704.00 ( 0.00%) 182996.00 (-135.50%)
Ops swapin-0M 24834.00 ( 0.00%) 8.00 ( 99.97%)
Ops swapin-435M 9038.00 ( 0.00%) 0.00 ( 0.00%)
Ops swapin-944M 26230.00 ( 0.00%) 42953.00 (-63.76%)
Ops swapin-1452M 25766.00 ( 0.00%) 68440.00 (-165.62%)
Ops swapin-1961M 27258.00 ( 0.00%) 68129.00 (-149.94%)
Ops swapin-2469M 28508.00 ( 0.00%) 82234.00 (-188.46%)
Ops swapin-2978M 37970.00 ( 0.00%) 89280.00 (-135.13%)
Ops minorfaults-0M 1460163.00 ( 0.00%) 927966.00 ( 36.45%)
Ops minorfaults-435M 954058.00 ( 0.00%) 936182.00 ( 1.87%)
Ops minorfaults-944M 972818.00 ( 0.00%) 1005956.00 ( -3.41%)
Ops minorfaults-1452M 966597.00 ( 0.00%) 1035465.00 ( -7.12%)
Ops minorfaults-1961M 976158.00 ( 0.00%) 1049441.00 ( -7.51%)
Ops minorfaults-2469M 967815.00 ( 0.00%) 1051752.00 ( -8.67%)
Ops minorfaults-2978M 988712.00 ( 0.00%) 1034615.00 ( -4.64%)
Ops majorfaults-0M 5899.00 ( 0.00%) 9.00 ( 99.85%)
Ops majorfaults-435M 2684.00 ( 0.00%) 67.00 ( 97.50%)
Ops majorfaults-944M 4380.00 ( 0.00%) 5790.00 (-32.19%)
Ops majorfaults-1452M 4161.00 ( 0.00%) 9222.00 (-121.63%)
Ops majorfaults-1961M 4435.00 ( 0.00%) 8800.00 (-98.42%)
Ops majorfaults-2469M 4555.00 ( 0.00%) 10541.00 (-131.42%)
Ops majorfaults-2978M 6182.00 ( 0.00%) 11618.00 (-87.93%)
But the performance of the first machine I used whose total ram size
is 2G is still bad.
I need more time to summarize those testing results.
Maybe you can also have a try with lower total ram size.
--
Regards,
--Bob
> From: Bob Liu [mailto:[email protected]]
Subject: Re: [PATCHv13 3/4] zswap: add to mm/
>
> On Thu, Jun 20, 2013 at 10:23 PM, Seth Jennings
> <[email protected]> wrote:
> > On Thu, Jun 20, 2013 at 05:42:04PM +0800, Bob Liu wrote:
> >> > Just made a mmtests run of my own and got very different results:
> >> >
> >>
> >> It's strange, I'll update to rc6 and try again.
> >> By the way, are you using 824 hardware compressor instead of lzo?
> >
> > My results where using lzo software compression.
> >
>
> Thanks, and today I used another machine to test zswap.
> The total ram size of that machine is around 4G.
> This time the result is better:
> rc6 rc6
> zswap base
> Ops memcachetest-0M 14619.00 ( 0.00%) 15602.00 ( 6.72%)
> Ops memcachetest-435M 14727.00 ( 0.00%) 15860.00 ( 7.69%)
> Ops memcachetest-944M 12452.00 ( 0.00%) 11812.00 ( -5.14%)
> Ops memcachetest-1452M 12183.00 ( 0.00%) 9829.00 (-19.32%)
> Ops memcachetest-1961M 11953.00 ( 0.00%) 9337.00 (-21.89%)
> Ops memcachetest-2469M 11201.00 ( 0.00%) 7509.00 (-32.96%)
> Ops memcachetest-2978M 9738.00 ( 0.00%) 5981.00 (-38.58%)
> Ops io-duration-0M 0.00 ( 0.00%) 0.00 ( 0.00%)
> Ops io-duration-435M 10.00 ( 0.00%) 6.00 ( 40.00%)
> Ops io-duration-944M 19.00 ( 0.00%) 19.00 ( 0.00%)
> Ops io-duration-1452M 31.00 ( 0.00%) 26.00 ( 16.13%)
> Ops io-duration-1961M 40.00 ( 0.00%) 35.00 ( 12.50%)
> Ops io-duration-2469M 45.00 ( 0.00%) 43.00 ( 4.44%)
> Ops io-duration-2978M 58.00 ( 0.00%) 53.00 ( 8.62%)
> Ops swaptotal-0M 56711.00 ( 0.00%) 8.00 ( 99.99%)
> Ops swaptotal-435M 19218.00 ( 0.00%) 2101.00 ( 89.07%)
> Ops swaptotal-944M 53233.00 ( 0.00%) 98055.00 (-84.20%)
> Ops swaptotal-1452M 52064.00 ( 0.00%) 145624.00 (-179.70%)
> Ops swaptotal-1961M 54960.00 ( 0.00%) 153907.00 (-180.03%)
> Ops swaptotal-2469M 57485.00 ( 0.00%) 176340.00 (-206.76%)
> Ops swaptotal-2978M 77704.00 ( 0.00%) 182996.00 (-135.50%)
> Ops swapin-0M 24834.00 ( 0.00%) 8.00 ( 99.97%)
> Ops swapin-435M 9038.00 ( 0.00%) 0.00 ( 0.00%)
> Ops swapin-944M 26230.00 ( 0.00%) 42953.00 (-63.76%)
> Ops swapin-1452M 25766.00 ( 0.00%) 68440.00 (-165.62%)
> Ops swapin-1961M 27258.00 ( 0.00%) 68129.00 (-149.94%)
> Ops swapin-2469M 28508.00 ( 0.00%) 82234.00 (-188.46%)
> Ops swapin-2978M 37970.00 ( 0.00%) 89280.00 (-135.13%)
> Ops minorfaults-0M 1460163.00 ( 0.00%) 927966.00 ( 36.45%)
> Ops minorfaults-435M 954058.00 ( 0.00%) 936182.00 ( 1.87%)
> Ops minorfaults-944M 972818.00 ( 0.00%) 1005956.00 ( -3.41%)
> Ops minorfaults-1452M 966597.00 ( 0.00%) 1035465.00 ( -7.12%)
> Ops minorfaults-1961M 976158.00 ( 0.00%) 1049441.00 ( -7.51%)
> Ops minorfaults-2469M 967815.00 ( 0.00%) 1051752.00 ( -8.67%)
> Ops minorfaults-2978M 988712.00 ( 0.00%) 1034615.00 ( -4.64%)
> Ops majorfaults-0M 5899.00 ( 0.00%) 9.00 ( 99.85%)
> Ops majorfaults-435M 2684.00 ( 0.00%) 67.00 ( 97.50%)
> Ops majorfaults-944M 4380.00 ( 0.00%) 5790.00 (-32.19%)
> Ops majorfaults-1452M 4161.00 ( 0.00%) 9222.00 (-121.63%)
> Ops majorfaults-1961M 4435.00 ( 0.00%) 8800.00 (-98.42%)
> Ops majorfaults-2469M 4555.00 ( 0.00%) 10541.00 (-131.42%)
> Ops majorfaults-2978M 6182.00 ( 0.00%) 11618.00 (-87.93%)
>
>
> But the performance of the first machine I used whose total ram size
> is 2G is still bad.
> I need more time to summarize those testing results.
>
> Maybe you can also have a try with lower total ram size.
>
> --
> Regards,
> --Bob
A very important factor that you are not considering and
that might account for your different results is the
"initial conditions". For example, I always ran my benchmarks
after a default-configured EL6 boot, which launches many services
at boot time, each of which creates many anonymous pages,
and these "service anonymous pages" are often the pages
that are selected by LRU for swapping, and compressed by zcache/zswap.
Someone else may run the benchmarks on a minimally-configured
embedded system, and someone else on a single-user system
with no services running at all. A single-user system with
no services is often best for reproducing benchmark results but
may not be at all representative of the real world.
At a minimum, it would be good to always record "Active(anon)"
and "Inactive(anon)" in addition to the amount of physical
RAM in the system. (Note, in /proc/meminfo on my system,
the sum of these don't add up to "AnonPages"... I'm not sure
why.)
And of course, even if the number of anonymous pages is
the same, the _contents_ of those pages may be very different,
which will affect zcache/zswap density which may have
a large impact on benchmark results.
Thanks,
Dan (T-minus two weeks and counting)
On Fri, Jun 21, 2013 at 08:20:34AM -0700, Dan Magenheimer wrote:
> > From: Bob Liu [mailto:[email protected]]
> Subject: Re: [PATCHv13 3/4] zswap: add to mm/
> >
> > On Thu, Jun 20, 2013 at 10:23 PM, Seth Jennings
> > <[email protected]> wrote:
> > > On Thu, Jun 20, 2013 at 05:42:04PM +0800, Bob Liu wrote:
> > >> > Just made a mmtests run of my own and got very different results:
> > >> >
> > >>
> > >> It's strange, I'll update to rc6 and try again.
> > >> By the way, are you using 824 hardware compressor instead of lzo?
> > >
> > > My results where using lzo software compression.
> > >
> >
> > Thanks, and today I used another machine to test zswap.
> > The total ram size of that machine is around 4G.
> > This time the result is better:
> > rc6 rc6
> > zswap base
> > Ops memcachetest-0M 14619.00 ( 0.00%) 15602.00 ( 6.72%)
> > Ops memcachetest-435M 14727.00 ( 0.00%) 15860.00 ( 7.69%)
> > Ops memcachetest-944M 12452.00 ( 0.00%) 11812.00 ( -5.14%)
> > Ops memcachetest-1452M 12183.00 ( 0.00%) 9829.00 (-19.32%)
> > Ops memcachetest-1961M 11953.00 ( 0.00%) 9337.00 (-21.89%)
> > Ops memcachetest-2469M 11201.00 ( 0.00%) 7509.00 (-32.96%)
> > Ops memcachetest-2978M 9738.00 ( 0.00%) 5981.00 (-38.58%)
> > Ops io-duration-0M 0.00 ( 0.00%) 0.00 ( 0.00%)
> > Ops io-duration-435M 10.00 ( 0.00%) 6.00 ( 40.00%)
> > Ops io-duration-944M 19.00 ( 0.00%) 19.00 ( 0.00%)
> > Ops io-duration-1452M 31.00 ( 0.00%) 26.00 ( 16.13%)
> > Ops io-duration-1961M 40.00 ( 0.00%) 35.00 ( 12.50%)
> > Ops io-duration-2469M 45.00 ( 0.00%) 43.00 ( 4.44%)
> > Ops io-duration-2978M 58.00 ( 0.00%) 53.00 ( 8.62%)
> > Ops swaptotal-0M 56711.00 ( 0.00%) 8.00 ( 99.99%)
> > Ops swaptotal-435M 19218.00 ( 0.00%) 2101.00 ( 89.07%)
> > Ops swaptotal-944M 53233.00 ( 0.00%) 98055.00 (-84.20%)
> > Ops swaptotal-1452M 52064.00 ( 0.00%) 145624.00 (-179.70%)
> > Ops swaptotal-1961M 54960.00 ( 0.00%) 153907.00 (-180.03%)
> > Ops swaptotal-2469M 57485.00 ( 0.00%) 176340.00 (-206.76%)
> > Ops swaptotal-2978M 77704.00 ( 0.00%) 182996.00 (-135.50%)
> > Ops swapin-0M 24834.00 ( 0.00%) 8.00 ( 99.97%)
> > Ops swapin-435M 9038.00 ( 0.00%) 0.00 ( 0.00%)
> > Ops swapin-944M 26230.00 ( 0.00%) 42953.00 (-63.76%)
> > Ops swapin-1452M 25766.00 ( 0.00%) 68440.00 (-165.62%)
> > Ops swapin-1961M 27258.00 ( 0.00%) 68129.00 (-149.94%)
> > Ops swapin-2469M 28508.00 ( 0.00%) 82234.00 (-188.46%)
> > Ops swapin-2978M 37970.00 ( 0.00%) 89280.00 (-135.13%)
> > Ops minorfaults-0M 1460163.00 ( 0.00%) 927966.00 ( 36.45%)
> > Ops minorfaults-435M 954058.00 ( 0.00%) 936182.00 ( 1.87%)
> > Ops minorfaults-944M 972818.00 ( 0.00%) 1005956.00 ( -3.41%)
> > Ops minorfaults-1452M 966597.00 ( 0.00%) 1035465.00 ( -7.12%)
> > Ops minorfaults-1961M 976158.00 ( 0.00%) 1049441.00 ( -7.51%)
> > Ops minorfaults-2469M 967815.00 ( 0.00%) 1051752.00 ( -8.67%)
> > Ops minorfaults-2978M 988712.00 ( 0.00%) 1034615.00 ( -4.64%)
> > Ops majorfaults-0M 5899.00 ( 0.00%) 9.00 ( 99.85%)
> > Ops majorfaults-435M 2684.00 ( 0.00%) 67.00 ( 97.50%)
> > Ops majorfaults-944M 4380.00 ( 0.00%) 5790.00 (-32.19%)
> > Ops majorfaults-1452M 4161.00 ( 0.00%) 9222.00 (-121.63%)
> > Ops majorfaults-1961M 4435.00 ( 0.00%) 8800.00 (-98.42%)
> > Ops majorfaults-2469M 4555.00 ( 0.00%) 10541.00 (-131.42%)
> > Ops majorfaults-2978M 6182.00 ( 0.00%) 11618.00 (-87.93%)
> >
> >
> > But the performance of the first machine I used whose total ram size
> > is 2G is still bad.
> > I need more time to summarize those testing results.
> >
> > Maybe you can also have a try with lower total ram size.
> >
> > --
> > Regards,
> > --Bob
>
>
> A very important factor that you are not considering and
> that might account for your different results is the
> "initial conditions". For example, I always ran my benchmarks
> after a default-configured EL6 boot, which launches many services
> at boot time, each of which creates many anonymous pages,
> and these "service anonymous pages" are often the pages
> that are selected by LRU for swapping, and compressed by zcache/zswap.
> Someone else may run the benchmarks on a minimally-configured
> embedded system, and someone else on a single-user system
> with no services running at all. A single-user system with
> no services is often best for reproducing benchmark results but
> may not be at all representative of the real world.
Right. And interestingly enough the kernbench recommends
that model so that it is easier to reproduce.
>
> At a minimum, it would be good to always record "Active(anon)"
> and "Inactive(anon)" in addition to the amount of physical
> RAM in the system. (Note, in /proc/meminfo on my system,
> the sum of these don't add up to "AnonPages"... I'm not sure
> why.)
>
> And of course, even if the number of anonymous pages is
> the same, the _contents_ of those pages may be very different,
> which will affect zcache/zswap density which may have
> a large impact on benchmark results.
>
> Thanks,
> Dan (T-minus two weeks and counting)
>