lkml.org 
[lkml]   [2020]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/1] rcu/tree: support kfree_bulk() interface in kfree_rcu()
    On Thu, Jan 16, 2020 at 06:27:53PM +0100, Uladzislau Rezki wrote:
    > 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.

    Sounds good, looking forward to it!

    Thanx, Paul

    \
     
     \ /
      Last update: 2020-01-16 18:54    [W:3.290 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site