All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.