From: Uladzislau Rezki <urezki@gmail.com>
To: "Paul E. McKenney" <paulmck@kernel.org>,
Michal Hocko <mhocko@suse.com>,
Thomas Gleixner <tglx@linutronix.de>
Cc: Michal Hocko <mhocko@suse.com>,
"Uladzislau Rezki (Sony)" <urezki@gmail.com>,
LKML <linux-kernel@vger.kernel.org>, RCU <rcu@vger.kernel.org>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Vlastimil Babka <vbabka@suse.cz>,
Thomas Gleixner <tglx@linutronix.de>,
"Theodore Y . Ts'o" <tytso@mit.edu>,
Joel Fernandes <joel@joelfernandes.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Subject: Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func.
Date: Wed, 23 Sep 2020 13:27:19 +0200 [thread overview]
Message-ID: <20200923112719.GA6796@pc636> (raw)
In-Reply-To: <20200922154621.GW29330@paulmck-ThinkPad-P72>
> > > Other approaches under consideration include making CONFIG_PREEMPT_COUNT
> > > unconditional and thus allowing call_rcu() and kvfree_rcu() to determine
> > > whether direct calls to the allocator are safe (some guy named Linus
> > > doesn't like this one),
> >
> > I assume that the primary argument is the overhead, right? Do you happen
> > to have any reference?
>
> Jon Corbet wrote a very nice article summarizing the current situation:
> https://lwn.net/Articles/831678/. Thomas's measurements show no visible
> system-level performance impact. I will let Uladzislau present his more
> microbenchmarky performance work.
>
I have done some analysis of the !PREEMPT kernel with and without PREEMPT_COUNT
configuration. The aim is to show a performance impact if the PREEMPT_COUNT is
unconditionally enabled.
As for the test i used the refscale kernel module, that does:
<snip>
static void ref_rcu_read_section(const int nloops)
{
int i;
for (i = nloops; i >= 0; i--) {
rcu_read_lock();
rcu_read_unlock();
}
}
<snip>
How to run the microbenchmark:
<snip>
urezki@pc638:~$ sudo modprobe refscale
<snip>
The below is an average duration per loop (nanoseconds):
!PREEMPT_COUNT PREEMPT_COUNT
Runs Time(ns) Runc Time(ns)
1 109.640 1 99.915
2 102.303 2 111.106
3 90.520 3 98.713
4 106.347 4 111.239
5 108.374 5 111.797
6 108.012 6 111.558
7 103.989 7 113.122
8 106.194 8 111.515
9 107.330 9 107.559
10 105.877 10 105.965
11 104.860 11 104.835
12 104.299 12 106.342
13 104.794 13 106.664
14 104.916 14 104.914
15 105.485 15 104.280
16 104.610 16 105.642
17 104.981 17 105.646
18 103.089 18 106.370
19 105.251 19 105.284
20 104.133 20 105.973
21 105.589 21 105.271
22 104.154 22 106.063
23 104.963 23 106.248
24 102.431 24 105.568
25 102.610 25 105.556
26 103.474 26 105.655
27 100.194 27 102.887
28 102.340 28 104.347
29 102.075 29 102.389
30 102.808 30 103.123
The difference is ~1.8% in average. The maximum value is 109.640 vs 113.122
The minimum value is 90.520 vs 98.713.
Tested on:
processor : 63
vendor_id : AuthenticAMD
cpu family : 6
model : 6
model name : QEMU Virtual CPU version 2.5+
cpu MHz : 3700.204
I also can do more detailed testing using "perf" tool.
--
Vlad Rezki
next prev parent reply other threads:[~2020-09-23 11:27 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-18 19:48 [PATCH 0/4] kvfree_rcu() and _LOCK_NESTING/_PREEMPT_RT Uladzislau Rezki (Sony)
2020-09-18 19:48 ` [PATCH 1/4] rcu/tree: Add a work to allocate pages from regular context Uladzislau Rezki (Sony)
2020-09-18 19:48 ` [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func Uladzislau Rezki (Sony)
2020-09-21 7:47 ` Michal Hocko
2020-09-21 15:45 ` Paul E. McKenney
2020-09-21 16:03 ` Michal Hocko
2020-09-21 19:48 ` Uladzislau Rezki
2020-09-22 7:50 ` Michal Hocko
2020-09-22 13:12 ` Uladzislau Rezki
2020-09-22 15:35 ` Michal Hocko
2020-09-23 10:37 ` Mel Gorman
2020-09-23 15:41 ` Paul E. McKenney
2020-09-23 23:22 ` Mel Gorman
2020-09-24 8:16 ` Uladzislau Rezki
2020-09-24 11:16 ` Peter Zijlstra
2020-09-24 15:16 ` Uladzislau Rezki
2020-09-24 11:19 ` Peter Zijlstra
2020-09-24 15:21 ` Uladzislau Rezki
2020-09-25 8:15 ` Peter Zijlstra
2020-09-25 10:25 ` Uladzislau Rezki
2020-09-24 15:38 ` Paul E. McKenney
2020-09-25 8:26 ` Peter Zijlstra
2020-09-26 14:37 ` Paul E. McKenney
2020-09-25 8:05 ` Michal Hocko
2020-09-25 15:31 ` Uladzislau Rezki
2020-09-25 15:47 ` Michal Hocko
2020-09-29 16:25 ` Uladzislau Rezki
2020-09-30 9:27 ` Michal Hocko
2020-09-30 12:35 ` Uladzislau Rezki
2020-09-30 12:44 ` Michal Hocko
2020-09-30 13:39 ` Uladzislau Rezki
2020-09-30 16:46 ` Michal Hocko
2020-09-30 20:36 ` Uladzislau Rezki
2020-09-30 15:25 ` Joel Fernandes
2020-09-30 16:48 ` Michal Hocko
2020-09-30 17:03 ` Joel Fernandes
2020-09-30 17:22 ` Michal Hocko
2020-09-30 17:48 ` Joel Fernandes
2020-09-25 16:17 ` Mel Gorman
2020-09-25 17:57 ` Uladzislau Rezki
2020-09-22 15:49 ` Paul E. McKenney
2020-09-22 3:35 ` Paul E. McKenney
2020-09-22 8:03 ` Michal Hocko
2020-09-22 15:46 ` Paul E. McKenney
2020-09-23 11:27 ` Uladzislau Rezki [this message]
2020-09-29 10:15 ` Vlastimil Babka
2020-09-29 22:07 ` Uladzislau Rezki
2020-09-30 10:35 ` Michal Hocko
2020-10-01 19:32 ` Uladzislau Rezki
2020-09-30 14:39 ` Vlastimil Babka
2020-09-30 15:37 ` Joel Fernandes
2020-10-01 19:26 ` Uladzislau Rezki
2020-10-02 7:11 ` Michal Hocko
2020-10-02 8:50 ` Mel Gorman
2020-10-02 9:05 ` Michal Hocko
2020-10-05 15:08 ` Uladzislau Rezki
2020-10-05 15:41 ` Michal Hocko
2020-10-06 22:25 ` Uladzislau Rezki
2020-10-07 10:02 ` Michal Hocko
2020-10-07 11:02 ` Uladzislau Rezki
2020-10-02 9:07 ` Peter Zijlstra
2020-10-02 9:45 ` Mel Gorman
2020-10-02 9:58 ` Peter Zijlstra
2020-10-02 10:19 ` Mel Gorman
2020-10-02 14:41 ` Paul E. McKenney
2020-10-06 10:03 ` Mel Gorman
2020-10-06 15:41 ` Paul E. McKenney
2020-10-05 13:58 ` Uladzislau Rezki
2020-10-02 8:06 ` Mel Gorman
2020-10-05 14:12 ` Uladzislau Rezki
2020-09-18 19:48 ` [PATCH 3/4] rcu/tree: use " Uladzislau Rezki (Sony)
2020-09-18 19:48 ` [PATCH 4/4] rcu/tree: Use schedule_delayed_work() instead of WQ_HIGHPRI queue Uladzislau Rezki (Sony)
2020-09-20 15:06 ` Paul E. McKenney
2020-09-21 13:27 ` Uladzislau Rezki
2020-09-18 22:15 ` [PATCH 0/4] kvfree_rcu() and _LOCK_NESTING/_PREEMPT_RT Paul E. McKenney
2020-09-30 15:52 ` Joel Fernandes
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=20200923112719.GA6796@pc636 \
--to=urezki@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bigeasy@linutronix.de \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=oleksiy.avramchenko@sonymobile.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rcu@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tytso@mit.edu \
--cc=vbabka@suse.cz \
/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;
as well as URLs for NNTP newsgroup(s).