From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Daniel Wagner <daniel.wagner@bmw-carit.de>,
Davidlohr Bueso <dave@stgolabs.net>,
Ingo Molnar <mingo@redhat.com>, Tejun Heo <tj@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/7] rcu: Create rcu_sync infrastructure
Date: Wed, 15 Jul 2015 12:15:21 -0700 [thread overview]
Message-ID: <20150715191521.GN3717@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150715190815.GC2101@redhat.com>
On Wed, Jul 15, 2015 at 09:08:15PM +0200, Oleg Nesterov wrote:
> On 07/15, Paul E. McKenney wrote:
> >
> > On Wed, Jul 15, 2015 at 08:15:11PM +0200, Peter Zijlstra wrote:
> > >
> > > No, it makes the read-side primitive contain an unconditional memory
> > > barrier, that forgoes the entire point.
> > >
> > > The writers are stupidly expensive already for they need global
> > > serialization, optimizing them in any way doesn't make sense.
> >
> > That could well be the case, but it would be good to see the numbers.
>
> Please see the discussion in another "change sb_writers to use
> percpu_rw_semaphore".
>
> The simple test-case from Dave
>
> #include <fcntl.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <string.h>
> #include <assert.h>
>
> #define BUFLEN 1
> #define FILESIZE (1 * 1024 * 1024)
>
> char *testcase_description = "Separate file write";
>
> void testcase(unsigned long long *iterations)
> {
> char buf[BUFLEN];
> char tmpfile[] = "/run/user/1000/willitscale.XXXXXX";
> int fd = mkstemp(tmpfile);
> unsigned long size = 0;
>
> memset(buf, 0, sizeof(buf));
> assert(fd >= 0);
> unlink(tmpfile);
>
> while (1) {
> int ret = write(fd, buf, BUFLEN);
> assert(ret >= 0);
> size += ret;
> if (size >= FILESIZE) {
> size = 0;
> lseek(fd, 0, SEEK_SET);
> }
>
> (*iterations)++;
> }
> }
>
> runs 12% faster if we "simply" remove mb's from sb_start/end_write().
> percpu_rw_semaphore does this too and has the approximately same
> performance, and we can (hopefully) remove this nontrivial, currently
> not 100% correct, and very "special" code in fs/super.c.
OK, if that is the type of workload you are using this stuff for,
you really don't want read-side memory barriers.
Thanx, Paul
next prev parent reply other threads:[~2015-07-15 19:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-11 23:35 [PATCH 0/7] Add rcu_sync infrastructure to avoid _expedited() in percpu-rwsem Oleg Nesterov
2015-07-11 23:35 ` [PATCH 1/7] rcu: Create rcu_sync infrastructure Oleg Nesterov
2015-07-15 18:05 ` Paul E. McKenney
2015-07-15 18:15 ` Peter Zijlstra
2015-07-15 18:28 ` Paul E. McKenney
2015-07-15 19:08 ` Oleg Nesterov
2015-07-15 19:15 ` Paul E. McKenney [this message]
2015-07-15 18:41 ` Oleg Nesterov
2015-07-11 23:35 ` [PATCH 2/7] rcusync: Introduce struct rcu_sync_ops Oleg Nesterov
2015-07-11 23:35 ` [PATCH 3/7] rcusync: Add the CONFIG_PROVE_RCU checks Oleg Nesterov
2015-07-11 23:35 ` [PATCH 4/7] rcusync: Introduce rcu_sync_dtor() Oleg Nesterov
2015-07-11 23:36 ` [PATCH 5/7] percpu-rwsem: change it to rely on rss_sync infrastructure Oleg Nesterov
2015-07-15 18:15 ` Paul E. McKenney
2015-07-15 18:59 ` Oleg Nesterov
2015-07-11 23:36 ` [PATCH 6/7] percpu-rwsem: fix the comments outdated by rcu_sync Oleg Nesterov
2015-07-11 23:36 ` [PATCH 7/7] percpu-rwsem: cleanup the lockdep annotations in percpu_down_read() Oleg Nesterov
2015-07-11 23:47 ` [PATCH 0/7] Add rcu_sync infrastructure to avoid _expedited() in percpu-rwsem Linus Torvalds
2015-07-15 18:27 ` Paul E. McKenney
2015-07-15 19:36 ` Oleg Nesterov
2015-07-15 21:59 ` Paul E. McKenney
2015-07-17 23:29 ` Oleg Nesterov
2015-07-17 23:47 ` Paul E. McKenney
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=20150715191521.GN3717@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=daniel.wagner@bmw-carit.de \
--cc=dave@stgolabs.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.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
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