[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161117124844.GD3117@twins.programming.kicks-ass.net>
Date: Thu, 17 Nov 2016 13:48:44 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Boqun Feng <boqun.feng@...il.com>, keescook@...omium.org,
will.deacon@....com, elena.reshetova@...el.com, arnd@...db.de,
tglx@...utronix.de, mingo@...nel.org, hpa@...or.com,
dave@...gbits.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 7/7] kref: Implement using refcount_t
On Thu, Nov 17, 2016 at 12:03:33PM +0100, Greg KH wrote:
> On Thu, Nov 17, 2016 at 11:39:27AM +0100, Peter Zijlstra wrote:
> > And let me note here that RCU users can use a fully relaxed put, because
> > call_rcu() guarantees a grace-period between the call_rcu and the
> > free(), which in turn provides a full memory barrier that orders things.
> >
> > We could actually expose that to driver writers by doing something like:
> >
> > kref_put_rcu(struct kref *kref, struct rcu_head *head, rcu_callback_t func)
> > {
> > if (refcount_dec_and_test_relaxed(&kref->refcount))
> > call_rcu(head, func);
> > }
> >
> > Do we want to go there?
>
> No, please no...
Hehe, fair enough. Although core kernel 'power' users might really want
that. The relaxed memory order stuff saves quite a few cycles on weak
archs.
Powered by blists - more mailing lists