RCU Archive on lore.kernel.org
 help / color / Atom feed
From: Uladzislau Rezki <urezki@gmail.com>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Joel Fernandes <joel@joelfernandes.org>,
	"Uladzislau Rezki (Sony)" <urezki@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>, RCU <rcu@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Subject: Re: [PATCH 1/1] rcu/tree: support kfree_bulk() interface in kfree_rcu()
Date: Thu, 16 Jan 2020 18:27:53 +0100
Message-ID: <20200116172753.GB23524@pc636> (raw)
In-Reply-To: <20200116024126.GS2935@paulmck-ThinkPad-P72>

On Wed, Jan 15, 2020 at 06:41:26PM -0800, Paul E. McKenney wrote:
> On Wed, Jan 15, 2020 at 08:14:10PM -0500, Joel Fernandes wrote:
> > On Tue, Dec 31, 2019 at 01:22:41PM +0100, Uladzislau Rezki (Sony) wrote:
> > > kfree_rcu() logic can be improved further by using kfree_bulk()
> > > interface along with "basic batching support" introduced earlier.
> > > 
> > > The are at least two advantages of using "bulk" interface:
> > > - in case of large number of kfree_rcu() requests kfree_bulk()
> > >   reduces the per-object overhead caused by calling kfree()
> > >   per-object.
> > > 
> > > - reduces the number of cache-misses due to "pointer chasing"
> > >   between objects which can be far spread between each other.
> > > 
> > > This approach defines a new kfree_rcu_bulk_data structure that
> > > stores pointers in an array with a specific size. Number of entries
> > > in that array depends on PAGE_SIZE making kfree_rcu_bulk_data
> > > structure to be exactly one page.
> > > 
> > > Since it deals with "block-chain" technique there is an extra
> > > need in dynamic allocation when a new block is required. Memory
> > > is allocated with GFP_NOWAIT | __GFP_NOWARN flags, i.e. that
> > > allows to skip direct reclaim under low memory condition to
> > > prevent stalling and fails silently under high memory pressure.
> > > 
> > > The "emergency path" gets maintained when a system is run out
> > > of memory. In that case objects are linked into regular list
> > > and that is it.
> > > 
> > > In order to evaluate it, the "rcuperf" was run to analyze how
> > > much memory is consumed and what is kfree_bulk() throughput.
> > > 
> > > Testing on the HiKey-960, arm64, 8xCPUs with below parameters:
> > > 
> > > CONFIG_SLAB=y
> > > kfree_loops=200000 kfree_alloc_num=1000 kfree_rcu_test=1
> > > 
> > > 102898760401 ns, loops: 200000, batches: 5822, memory footprint: 158MB
> > > 89947009882  ns, loops: 200000, batches: 6715, memory footprint: 115MB
> > > 
> > > rcuperf shows approximately ~12% better throughput(Total time)
> > > in case of using "bulk" interface. The "drain logic" or its RCU
> > > callback does the work faster that leads to better throughput.
> > 
> > Tested-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> > 
> > (Vlad is going to post a v2 which fixes a debugobjects bug but that should
> > not have any impact on testing).
> 
> Very good!  Uladzislau, could you please add Joel's Tested-by in
> your next posting?
> 
I will add for sure, with the a V2 version. Also, i will update the
commit message by adding the results related to different slab cache
usage, i mean with Joel's recent patch.

Thank you.

--
Vlad Rezki

  reply index

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-31 12:22 Uladzislau Rezki (Sony)
2020-01-13 19:03 ` Paul E. McKenney
2020-01-14 16:49   ` Joel Fernandes
2020-01-15 13:14     ` Uladzislau Rezki
2020-01-15 22:53       ` Joel Fernandes
2020-01-17 17:52         ` Uladzislau Rezki
2020-01-17 18:57           ` Joel Fernandes
2020-01-17 21:37             ` Paul E. McKenney
2020-01-17 21:59               ` Joel Fernandes
2020-01-16  1:14 ` Joel Fernandes
2020-01-16  2:41   ` Paul E. McKenney
2020-01-16 17:27     ` Uladzislau Rezki [this message]
2020-01-16 17:44       ` Paul E. McKenney
2020-01-16 17:24   ` Uladzislau Rezki
  -- strict thread matches above, loose matches on Subject: below --
2019-12-20 12:56 Uladzislau Rezki (Sony)
2019-12-21 23:21 ` Joel Fernandes
2019-12-24 18:49   ` Uladzislau Rezki

Reply instructions:

You may reply publically 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=20200116172753.GB23524@pc636 \
    --to=urezki@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleksiy.avramchenko@sonymobile.com \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

RCU Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/rcu/0 rcu/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 rcu rcu/ https://lore.kernel.org/rcu \
		rcu@vger.kernel.org
	public-inbox-index rcu

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.rcu


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git