From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>,
intel-gfx@lists.freedesktop.org, Linux MM <linux-mm@kvack.org>,
Jens Axboe <jens.axboe@oracle.com>,
Christoph Lameter <cl@linux-foundation.org>,
Hugh Dickins <hugh@veritas.com>,
Pekka Enberg <penberg@cs.helsinki.fi>
Subject: Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Enable lockless lookup of request tracking via RCU
Date: Tue, 5 Jan 2016 08:35:37 -0800 [thread overview]
Message-ID: <20160105163537.GL32217@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160105150648.GT6373@twins.programming.kicks-ass.net>
On Tue, Jan 05, 2016 at 04:06:48PM +0100, Peter Zijlstra wrote:
> On Tue, Jan 05, 2016 at 04:02:13PM +0100, Peter Zijlstra wrote:
> > > Shouldn't the slab subsystem do this for us if we request it delays the
> > > actual kfree? Seems like a core bug to me ... Adding more folks.
> >
> > note that sync_rcu() can take a terribly long time.. but yes, I seem to
> > remember Paul talking about adding this to reclaim paths for just this
> > reason. Not sure that ever happened thouhg.
There is an RCU OOM notifier, but it just ensures that existing callbacks
get processed in a timely fashion. It does not block, as that would
prevent other OOM notifiers from getting their memory freed quickly.
> Also, you might be wanting rcu_barrier() instead, that not only waits
> for a GP to complete, but also for all pending callbacks to be
> processed.
And in fact what the RCU OOM notifier does can be thought of as an
asynchronous open-coded rcu_barrier(). If you are interested, please
see rcu_register_oom_notifier() and friends.
> Without the latter there might still not be anything to free after it.
Another approach is synchronize_rcu() after some largish number of
requests. The advantage of this approach is that it throttles the
production of callbacks at the source. The corresponding disadvantage
is that it slows things up.
Another approach is to use call_rcu(), but if the previous call_rcu()
is still in flight, block waiting for it. Yet another approach is
the get_state_synchronize_rcu() / cond_synchronize_rcu() pair. The
idea is to do something like this:
cond_synchronize_rcu(cookie);
cookie = get_state_synchronize_rcu();
You would of course do an initial get_state_synchronize_rcu() to
get things going. This would not block unless there was less than
one grace period's worth of time between invocations. But this
assumes a busy system, where there is almost always a grace period
in flight. But you can make that happen as follows:
cond_synchronize_rcu(cookie);
cookie = get_state_synchronize_rcu();
call_rcu(&my_rcu_head, noop_function);
Note that you need additional code to make sure that the old callback
has completed before doing a new one. Setting and clearing a flag
with appropriate memory ordering control suffices (e.g,. smp_load_acquire()
and smp_store_release()).
And there are probably other approaches as well...
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>
next prev parent reply other threads:[~2016-01-05 16:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1450869563-23892-1-git-send-email-chris@chris-wilson.co.uk>
[not found] ` <1450877756-2902-1-git-send-email-chris@chris-wilson.co.uk>
2016-01-05 14:59 ` [Intel-gfx] [PATCH v2 1/3] drm/i915: Enable lockless lookup of request tracking via RCU Daniel Vetter
2016-01-05 15:02 ` Peter Zijlstra
2016-01-05 15:06 ` Peter Zijlstra
2016-01-05 16:35 ` Paul E. McKenney [this message]
2016-01-06 8:06 ` Daniel Vetter
2016-01-06 8:38 ` Peter Zijlstra
2016-01-06 15:56 ` 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=20160105163537.GL32217@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=chris@chris-wilson.co.uk \
--cc=cl@linux-foundation.org \
--cc=hugh@veritas.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jens.axboe@oracle.com \
--cc=linux-mm@kvack.org \
--cc=penberg@cs.helsinki.fi \
--cc=peterz@infradead.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;
as well as URLs for NNTP newsgroup(s).