Re: [PATCH v4 2/2] rcuperf: Add kfree_rcu() performance Tests

From: Joel Fernandes <joel@joelfernandes.org>
To: "Paul E. McKenney" <paulmck@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org, byungchul.park@lge.com,
	Davidlohr Bueso <dave@stgolabs.net>,
	Josh Triplett <josh@joshtriplett.org>,
	kernel-team@android.com, kernel-team@lge.com,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	max.byungchul.park@gmail.com, Rao Shoaib <rao.shoaib@oracle.com>,
	rcu@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH v4 2/2] rcuperf: Add kfree_rcu() performance Tests
Date: Tue, 20 Aug 2019 20:51:54 -0400	[thread overview]
Message-ID: <20190821005154.GA27466@google.com> (raw)
In-Reply-To: <20190821004436.GB28441@linux.ibm.com>

On Tue, Aug 20, 2019 at 05:44:36PM -0700, Paul E. McKenney wrote:
> On Tue, Aug 20, 2019 at 08:31:32PM -0400, Joel Fernandes wrote:
> > On Tue, Aug 20, 2019 at 08:27:05PM -0400, Joel Fernandes wrote:
> > [snip]
> > > > > > Or is the idea to time the kfree_rcu() loop separately?  (I don't see
> > > > > > any such separate timing, though.)
> > > > > 
> > > > > The kmalloc() times are included within the kfree loop. The timing of
> > > > > kfree_rcu() is not separate in my patch.
> > > > 
> > > > You lost me on this one.  What happens when you just interleave the
> > > > kmalloc() and kfree_rcu(), without looping, compared to the looping
> > > > above?  Does this get more expensive?  Cheaper?  More vulnerable to OOM?
> > > > Something else?
> > > 
> > > You mean pairing a single kmalloc() with a single kfree_rcu() and doing this
> > > several times? The results are very similar to doing kfree_alloc_num
> > > kmalloc()s, then do kfree_alloc_num kfree_rcu()s; and repeat the whole thing
> > > kfree_loops times (as done by this rcuperf patch we are reviewing).
> > > 
> > > Following are some numbers. One change is the case where we are not at all
> > > batching does seem to complete even faster when we fully interleave kmalloc()
> > > with kfree() while the case of batching in the same scenario completes at the
> > > same time as did the "not fully interleaved" scenario. However, the grace
> > > period reduction improvements and the chances of OOM'ing are pretty much the
> > > same in either case.
> > [snip]
> > > Not fully interleaved: do kfree_alloc_num kmallocs, then do kfree_alloc_num kfree_rcu()s. And repeat this kfree_loops times.
> > > =======================
> > > (1) Batching
> > > rcuperf.kfree_loops=20000 rcuperf.kfree_alloc_num=8000 rcuperf.kfree_no_batch=0 rcuperf.kfree_rcu_test=1
> > > 
> > > root@(none):/# free -m
> > >               total        used        free      shared  buff/cache   available
> > > Mem:            977         251         686           0          39         684
> > > Swap:             0           0           0
> > > 
> > > [   15.574402] Total time taken by all kfree'ers: 14185970787 ns, loops: 20000, batches: 1548
> > > 
> > > (2) No Batching
> > > rcuperf.kfree_loops=20000 rcuperf.kfree_alloc_num=8000 rcuperf.kfree_no_batch=1 rcuperf.kfree_rcu_test=1
> > > 
> > > root@(none):/# free -m
> > >               total        used        free      shared  buff/cache   available
> > > Mem:            977          82         855           0          39         853
> > > Swap:             0           0           0
> > > 
> > > [   13.724554] Total time taken by all kfree'ers: 12246217291 ns, loops: 20000, batches: 7262
> > 
> > And the diff for changing the test to do this case is as follows (I don't
> > plan to fold this diff in, since I feel the existing test suffices and
> > results are similar):
> 
> But why not?  It does look to be a nice simplification, after all.

That's true. Ok, I'll squash it in. thanks!

thanks,

 - Joel
[snip]