Date:	Sat, 9 Jan 2016 13:11:55 +0100
From:	Andreas Grünbacher <andreas.gruenbacher@...il.com>
To:	Jan Kara <jack@...e.cz>
Cc:	Ted Tso <tytso@....edu>, Andreas Dilger <adilger@...ger.ca>,
	Laurent GUERBY <laurent@...rby.net>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/7] mbcache2: Reimplement mbcache

2015-12-16 18:00 GMT+01:00 Jan Kara <jack@...e.cz>:
> Original mbcache was designed to have more features than what ext?
> filesystems ended up using. It supported entry being in more hashes, it
> had a home-grown rwlocking of each entry, and one cache could cache
> entries from multiple filesystems. This genericity also resulted in more
> complex locking, larger cache entries, and generally more code
> complexity.
>
> This is reimplementation of the mbcache functionality to exactly fit the
> purpose ext? filesystems use it for. Cache entries are now considerably
> smaller (7 instead of 13 longs), the code is considerably smaller as
> well (414 vs 913 lines of code), and IMO also simpler. The new code is
> also much more lightweight.
>
> I have measured the speed using artificial xattr-bench benchmark, which
> spawns P processes, each process sets xattr for F different files, and
> the value of xattr is randomly chosen from a pool of V values. Averages
> of runtimes for 5 runs for various combinations of parameters are below.
> The first value in each cell is old mbache, the second value is the new
> mbcache.
>
> V=10
> F\P     1               2               4               8               16              32              64
> 10      0.158,0.157     0.208,0.196     0.500,0.277     0.798,0.400     3.258,0.584     13.807,1.047    61.339,2.803
> 100     0.172,0.167     0.279,0.222     0.520,0.275     0.825,0.341     2.981,0.505     12.022,1.202    44.641,2.943
> 1000    0.185,0.174     0.297,0.239     0.445,0.283     0.767,0.340     2.329,0.480     6.342,1.198     16.440,3.888
>
> V=100
> F\P     1               2               4               8               16              32              64
> 10      0.162,0.153     0.200,0.186     0.362,0.257     0.671,0.496     1.433,0.943     3.801,1.345     7.938,2.501
> 100     0.153,0.160     0.221,0.199     0.404,0.264     0.945,0.379     1.556,0.485     3.761,1.156     7.901,2.484
> 1000    0.215,0.191     0.303,0.246     0.471,0.288     0.960,0.347     1.647,0.479     3.916,1.176     8.058,3.160
>
> V=1000
> F\P     1               2               4               8               16              32              64
> 10      0.151,0.129     0.210,0.163     0.326,0.245     0.685,0.521     1.284,0.859     3.087,2.251     6.451,4.801
> 100     0.154,0.153     0.211,0.191     0.276,0.282     0.687,0.506     1.202,0.877     3.259,1.954     8.738,2.887
> 1000    0.145,0.179     0.202,0.222     0.449,0.319     0.899,0.333     1.577,0.524     4.221,1.240     9.782,3.579
>
> V=10000
> F\P     1               2               4               8               16              32              64
> 10      0.161,0.154     0.198,0.190     0.296,0.256     0.662,0.480     1.192,0.818     2.989,2.200     6.362,4.746
> 100     0.176,0.174     0.236,0.203     0.326,0.255     0.696,0.511     1.183,0.855     4.205,3.444     19.510,17.760
> 1000    0.199,0.183     0.240,0.227     1.159,1.014     2.286,2.154     6.023,6.039     ---,10.933      ---,36.620
>
> V=100000
> F\P     1               2               4               8               16              32              64
> 10      0.171,0.162     0.204,0.198     0.285,0.230     0.692,0.500     1.225,0.881     2.990,2.243     6.379,4.771
> 100     0.151,0.171     0.220,0.210     0.295,0.255     0.720,0.518     1.226,0.844     3.423,2.831     19.234,17.544
> 1000    0.192,0.189     0.249,0.225     1.162,1.043     2.257,2.093     5.853,4.997     ---,10.399      ---,32.198
>
> We see that the new code is faster in pretty much all the cases and
> starting from 4 processes there are significant gains with the new code
> resulting in upto 20-times shorter runtimes. Also for large numbers of
> cached entries all values for the old code could not be measured as the
> kernel started hitting softlockups and died before the test completed.
>
> Signed-off-by: Jan Kara <jack@...e.cz>
> ---
>  fs/Makefile              |   2 +-
>  fs/mbcache2.c            | 362 +++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/mbcache2.h |  52 +++++++
>  3 files changed, 415 insertions(+), 1 deletion(-)
>  create mode 100644 fs/mbcache2.c
>  create mode 100644 include/linux/mbcache2.h
>
> diff --git a/fs/Makefile b/fs/Makefile
> index 79f522575cba..15b3d6c4e46a 100644
> --- a/fs/Makefile
> +++ b/fs/Makefile
> @@ -41,7 +41,7 @@ obj-$(CONFIG_COMPAT_BINFMT_ELF)       += compat_binfmt_elf.o
>  obj-$(CONFIG_BINFMT_ELF_FDPIC) += binfmt_elf_fdpic.o
>  obj-$(CONFIG_BINFMT_FLAT)      += binfmt_flat.o
>
> -obj-$(CONFIG_FS_MBCACHE)       += mbcache.o
> +obj-$(CONFIG_FS_MBCACHE)       += mbcache.o mbcache2.o
>  obj-$(CONFIG_FS_POSIX_ACL)     += posix_acl.o
>  obj-$(CONFIG_NFS_COMMON)       += nfs_common/
>  obj-$(CONFIG_COREDUMP)         += coredump.o
> diff --git a/fs/mbcache2.c b/fs/mbcache2.c
> new file mode 100644
> index 000000000000..283c46e62f5f
> --- /dev/null
> +++ b/fs/mbcache2.c
> @@ -0,0 +1,362 @@
> +#include <linux/spinlock.h>
> +#include <linux/slab.h>
> +#include <linux/list.h>
> +#include <linux/list_bl.h>
> +#include <linux/module.h>
> +#include <linux/sched.h>
> +#include <linux/mbcache2.h>
> +
> +/*
> + * Mbcache is a simple key-value store. Keys need not be unique, however
> + * key-value pairs are expected to be unique (we use this fact in
> + * mb2_cache_entry_delete_block()).
> + *
> + * Ext2 and ext4 use this cache for deduplication of extended attribute blocks.

The term deduplication usually refers to removing existing duplicates;
 here we're trying to avoid creating duplicates in the first place
though.

Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists