All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"minchan.kim@gmail.com" <minchan.kim@gmail.com>,
	cl@linux-foundation.org,
	"hugh.dickins" <hugh.dickins@tiscali.co.uk>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Ingo Molnar <mingo@elte.hu>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RFC PATCH] asynchronous page fault.
Date: Mon, 4 Jan 2010 08:56:52 -0800	[thread overview]
Message-ID: <20100104165652.GC6748@linux.vnet.ibm.com> (raw)
In-Reply-To: <1262620974.6408.169.camel@laptop>

On Mon, Jan 04, 2010 at 05:02:54PM +0100, Peter Zijlstra wrote:
> On Mon, 2010-01-04 at 07:55 -0800, Paul E. McKenney wrote:
> > > Well, I was thinking srcu to have this force quiescent state in
> > > call_srcu() much like you did for the preemptible rcu.
> > 
> > Ah, so the idea would be that you register a function with the srcu_struct
> > that is invoked when some readers are stuck for too long in their SRCU
> > read-side critical sections?  Presumably you also supply a time value for
> > "too long" as well.  Hmmm...  What do you do, cancel the corresponding
> > I/O or something? 
> 
> Hmm, I was more thinking along the lines of:
> 
> say IDX is the current counter idx.
> 
> if (pending > thresh) {
>   flush(!IDX)

This flushes pending I/Os?

>   force_flip_counter();

If this is internal to SRCU, what it would do is check for CPUs being
offline or in dyntick-idle state.  Or was your thought that this is
where I invoke callbacks into your code to do whatever can be done to
wake up the sleeping readers?

> }
> 
> Since we explicitly hold a reference on IDX, we can actually wait for !
> IDX to reach 0 and flush those callbacks.

One other thing -- if I merge SRCU into the tree-based infrastructure,
I should be able to eliminate the need for srcu_read_lock() to return
the index (and thus for srcu_read_unlock() to take it as an argument).
So the index would be strictly internal, as it currently is with the
other flavors of RCU.

> We then force-flip the counter, so that even if all callbacks (or the
> majority) were not for !IDX but part of IDX, we'd be able to flush them
> on the next call_srcu() because that will then hold a ref on the new
> counter index.

We can certainly defer callbacks to a later grace period.  What we cannot
do is advance the counter until all readers for the current grace period
have exited their SRCU read-side critical sections.

> Or am I missing something obvious?

Or maybe I am.

							Thanx, Paul

WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"minchan.kim@gmail.com" <minchan.kim@gmail.com>,
	cl@linux-foundation.org,
	"hugh.dickins" <hugh.dickins@tiscali.co.uk>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Ingo Molnar <mingo@elte.hu>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RFC PATCH] asynchronous page fault.
Date: Mon, 4 Jan 2010 08:56:52 -0800	[thread overview]
Message-ID: <20100104165652.GC6748@linux.vnet.ibm.com> (raw)
In-Reply-To: <1262620974.6408.169.camel@laptop>

On Mon, Jan 04, 2010 at 05:02:54PM +0100, Peter Zijlstra wrote:
> On Mon, 2010-01-04 at 07:55 -0800, Paul E. McKenney wrote:
> > > Well, I was thinking srcu to have this force quiescent state in
> > > call_srcu() much like you did for the preemptible rcu.
> > 
> > Ah, so the idea would be that you register a function with the srcu_struct
> > that is invoked when some readers are stuck for too long in their SRCU
> > read-side critical sections?  Presumably you also supply a time value for
> > "too long" as well.  Hmmm...  What do you do, cancel the corresponding
> > I/O or something? 
> 
> Hmm, I was more thinking along the lines of:
> 
> say IDX is the current counter idx.
> 
> if (pending > thresh) {
>   flush(!IDX)

This flushes pending I/Os?

>   force_flip_counter();

If this is internal to SRCU, what it would do is check for CPUs being
offline or in dyntick-idle state.  Or was your thought that this is
where I invoke callbacks into your code to do whatever can be done to
wake up the sleeping readers?

> }
> 
> Since we explicitly hold a reference on IDX, we can actually wait for !
> IDX to reach 0 and flush those callbacks.

One other thing -- if I merge SRCU into the tree-based infrastructure,
I should be able to eliminate the need for srcu_read_lock() to return
the index (and thus for srcu_read_unlock() to take it as an argument).
So the index would be strictly internal, as it currently is with the
other flavors of RCU.

> We then force-flip the counter, so that even if all callbacks (or the
> majority) were not for !IDX but part of IDX, we'd be able to flush them
> on the next call_srcu() because that will then hold a ref on the new
> counter index.

We can certainly defer callbacks to a later grace period.  What we cannot
do is advance the counter until all readers for the current grace period
have exited their SRCU read-side critical sections.

> Or am I missing something obvious?

Or maybe I am.

							Thanx, Paul

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-01-04 16:57 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-25  1:51 [RFC PATCH] asynchronous page fault KAMEZAWA Hiroyuki
2009-12-27  9:47 ` Minchan Kim
2009-12-27  9:47   ` Minchan Kim
2009-12-27 23:59   ` KAMEZAWA Hiroyuki
2009-12-27 23:59     ` KAMEZAWA Hiroyuki
2009-12-27 11:19 ` Peter Zijlstra
2009-12-27 11:19   ` Peter Zijlstra
2009-12-28  0:00   ` KAMEZAWA Hiroyuki
2009-12-28  0:00     ` KAMEZAWA Hiroyuki
2009-12-28  0:57   ` Balbir Singh
2009-12-28  0:57     ` Balbir Singh
2009-12-28  1:05     ` KAMEZAWA Hiroyuki
2009-12-28  1:05       ` KAMEZAWA Hiroyuki
2009-12-28  2:58       ` Balbir Singh
2009-12-28  2:58         ` Balbir Singh
2009-12-28  3:13         ` KAMEZAWA Hiroyuki
2009-12-28  3:13           ` KAMEZAWA Hiroyuki
2009-12-28  8:34         ` Peter Zijlstra
2009-12-28  8:34           ` Peter Zijlstra
2009-12-28  8:32     ` Peter Zijlstra
2009-12-28  8:32       ` Peter Zijlstra
2009-12-29  9:54       ` Balbir Singh
2009-12-29  9:54         ` Balbir Singh
2009-12-27 12:03 ` Peter Zijlstra
2009-12-27 12:03   ` Peter Zijlstra
2009-12-28  0:36   ` KAMEZAWA Hiroyuki
2009-12-28  0:36     ` KAMEZAWA Hiroyuki
2009-12-28  1:19     ` KAMEZAWA Hiroyuki
2009-12-28  1:19       ` KAMEZAWA Hiroyuki
2009-12-28  8:30     ` Peter Zijlstra
2009-12-28  8:30       ` Peter Zijlstra
2009-12-28  9:58       ` KAMEZAWA Hiroyuki
2009-12-28  9:58         ` KAMEZAWA Hiroyuki
2009-12-28 10:30         ` Peter Zijlstra
2009-12-28 10:30           ` Peter Zijlstra
2009-12-28 10:40           ` Peter Zijlstra
2009-12-28 10:40             ` Peter Zijlstra
2010-01-02 16:14             ` Peter Zijlstra
2010-01-02 16:14               ` Peter Zijlstra
2010-01-04  3:02               ` Paul E. McKenney
2010-01-04  3:02                 ` Paul E. McKenney
2010-01-04  7:53                 ` Peter Zijlstra
2010-01-04  7:53                   ` Peter Zijlstra
2010-01-04 15:55                   ` Paul E. McKenney
2010-01-04 15:55                     ` Paul E. McKenney
2010-01-04 16:02                     ` Peter Zijlstra
2010-01-04 16:02                       ` Peter Zijlstra
2010-01-04 16:56                       ` Paul E. McKenney [this message]
2010-01-04 16:56                         ` Paul E. McKenney
2010-01-04 13:48               ` [RFC PATCH -v2] speculative " Peter Zijlstra
2010-01-04 13:48                 ` Peter Zijlstra
2009-12-28 10:57           ` [RFC PATCH] asynchronous " KAMEZAWA Hiroyuki
2009-12-28 10:57             ` KAMEZAWA Hiroyuki
2009-12-28 11:06             ` Peter Zijlstra
2009-12-28 11:06               ` Peter Zijlstra
2009-12-28  8:55     ` Peter Zijlstra
2009-12-28  8:55       ` Peter Zijlstra
2009-12-28 10:08       ` KAMEZAWA Hiroyuki
2009-12-28 10:08         ` KAMEZAWA Hiroyuki
2009-12-28 11:43     ` Peter Zijlstra
2009-12-28 11:43       ` Peter Zijlstra
2010-01-02 21:45 ` Benjamin Herrenschmidt
2010-01-02 21:45   ` Benjamin Herrenschmidt

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=20100104165652.GC6748@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=cl@linux-foundation.org \
    --cc=hugh.dickins@tiscali.co.uk \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan.kim@gmail.com \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=peterz@infradead.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.