From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Dave Hansen <dave@sr71.net>, Andi Kleen <ak@linux.intel.com>,
dave.hansen@linux.intel.com, akpm@linux-foundation.org,
jack@suse.cz, viro@zeniv.linux.org.uk, eparis@redhat.com,
john@johnmccutchan.com, rlove@rlove.org,
tim.c.chen@linux.intel.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] fs: optimize inotify/fsnotify code for unwatched files
Date: Mon, 22 Jun 2015 17:29:59 -0700 [thread overview]
Message-ID: <20150623002959.GE3892@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150622185229.GX3644@twins.programming.kicks-ass.net>
On Mon, Jun 22, 2015 at 08:52:29PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 22, 2015 at 08:11:21AM -0700, Paul E. McKenney wrote:
> > That depends on how slow the resulting slow global state would be.
> > We have some use cases (definitely KVM, perhaps also some of the VFS
> > code) that need the current speed, as opposed to the profound slowness
> > that three trips through synchronize_sched() would provide.
>
> So what we have with that percpu-rwsem code that I send out earlier
> today is a conditional smp_mb(), and I think we can do the same for
> SRCU.
>
> I'm just not sure !GP is common enough for all SRCU cases to be worth
> doing.
Especially given that we don't want the readers to have to acquire a
lock in order to get a consistent view of whether or not a grace period
is in progress.
> Those that rely on sync_srcu() and who do it rarely would definitely
> benefit. The same with those that rarely do call_srcu().
>
> But those that heavily use call_srcu() would be better off with the
> prolonged GP with 3 sync_sched() calls in.
Those are indeed two likely possibilities. Other possibilities include
cases where synchronize_srcu() is invoked rarely, but where its latency
is visible to userspace, and those where there really is a need to
wait synchronously for a grace period, so that call_srcu() doesn't buy
you anything.
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2015-06-23 0:30 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-19 21:50 [RFC][PATCH] fs: optimize inotify/fsnotify code for unwatched files Dave Hansen
2015-06-19 23:33 ` Andi Kleen
2015-06-20 0:29 ` Paul E. McKenney
2015-06-20 0:39 ` Dave Hansen
2015-06-20 2:21 ` Paul E. McKenney
2015-06-20 18:02 ` Dave Hansen
2015-06-21 1:30 ` Paul E. McKenney
2015-06-22 13:28 ` Peter Zijlstra
2015-06-22 15:11 ` Paul E. McKenney
2015-06-22 15:20 ` Peter Zijlstra
2015-06-22 16:29 ` Paul E. McKenney
2015-06-22 19:03 ` Peter Zijlstra
2015-06-23 0:31 ` Paul E. McKenney
2015-06-22 18:50 ` Dave Hansen
2015-06-23 0:26 ` Paul E. McKenney
2015-06-24 16:50 ` Dave Hansen
2015-06-24 17:29 ` Paul E. McKenney
2015-06-22 18:52 ` Peter Zijlstra
2015-06-23 0:29 ` Paul E. McKenney [this message]
2015-06-23 15:17 ` Jan Kara
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=20150623002959.GE3892@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=dave@sr71.net \
--cc=eparis@redhat.com \
--cc=jack@suse.cz \
--cc=john@johnmccutchan.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rlove@rlove.org \
--cc=tim.c.chen@linux.intel.com \
--cc=viro@zeniv.linux.org.uk \
/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.