linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@purestorage.com>
To: vitaly.wool@konsulko.com
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	ddstreet@ieee.org, akpm@linux-foundation.org,
	sjenning@redhat.com, johannes@sipsolutions.net
Subject: Re: [PATCH] zswap: use B-tree for search
Date: Mon, 18 Nov 2019 11:04:30 -0800	[thread overview]
Message-ID: <20191118190430.GA16134@cork> (raw)
In-Reply-To: <20191117185332.18998-1-vitaly.wool@konsulko.com>

On Sun, Nov 17, 2019 at 08:53:32PM +0200, vitaly.wool@konsulko.com wrote:
> From: Vitaly Wool <vitaly.wool@konsulko.com>
> 
> The current zswap implementation uses red-black trees to store
> entries and to perform lookups. Although this algorithm obviously
> has complexity of O(log N) it still takes a while to complete
> lookup (or, even more for replacement) of an entry, when the amount
> of entries is huge (100K+).
> 
> B-trees are known to handle such cases more efficiently (i. e. also
> with O(log N) complexity but with way lower coefficient) so trying
> zswap with B-trees was worth a shot.
> 
> The implementation of B-trees that is currently present in Linux
> kernel isn't really doing things in the best possible way (i. e. it
> has recursion) but the testing I've run still shows a very
> significant performance increase.
> 
> The usage pattern of B-tree here is not exactly following the
> guidelines but it is due to the fact that pgoff_t may be both 32
> and 64 bits long.
> 
> Tested on qemu-kvm (-smp 2 -m 1024) with zswap in the following
> configuration:
> * zpool: z3fold
> * max_pool_percent: 100
> and the swap size of 1G.
> 
> Test command:
> $ stress-ng --io 4 --vm 4 --vm-bytes 1000M --timeout 300s --metrics
> 
> This, averaged over 20 runs on qemu-kvm (-smp 2 -m 1024) gives the
> following io bogo ops:
> * original: 73778.8
> * btree: 393999

Impressive results.  Was your test done with a 32bit guest?  If yes, I
would assume results for a 64bit guess to drop to about 330k.

> +	if (sizeof(pgoff_t) == 8)
> +		btree_pgofft_geo = &btree_geo64;
> +	else
> +		btree_pgofft_geo = &btree_geo32;
> +

You could abuse the fact that pgoff_t is the same size as unsigned long
and use the "l" suffix variant.  But apart from the obvious abuse, the
"l" variant hasn't been used before and the implementation appears to be
buggy.

So no complaints about your use of the interface.

Jörn

--
Cryptographic protocols should not be designed by a committee.
-- Niels Ferguson & Bruce Schneier


  reply	other threads:[~2019-11-18 19:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-17 18:53 vitaly.wool
2019-11-18 19:04 ` Jörn Engel [this message]
2019-11-18 21:59   ` Vitaly Wool

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20191118190430.GA16134@cork \
    --to=joern@purestorage.com \
    --cc=akpm@linux-foundation.org \
    --cc=ddstreet@ieee.org \
    --cc=johannes@sipsolutions.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=sjenning@redhat.com \
    --cc=vitaly.wool@konsulko.com \
    /path/to/YOUR_REPLY

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

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