From: "Paul E. McKenney" <paulmck@us.ibm.com>
To: Matt Helsley <matthltc@us.ibm.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
linux-kernel@us.ibm.com, Andrew Morton <akpm@osdl.org>,
dipankar@in.ibm.com, Ingo Molnar <mingo@elte.hu>,
tytso@us.ibm.com, Darren Hart <dvhltc@us.ibm.com>,
oleg@tv-sign.ru, Jes Sorensen <jes@sgi.com>
Subject: Re: [PATCH 1/2] srcu-3: RCU variant permitting read-side blocking
Date: Thu, 6 Jul 2006 16:39:09 -0700 [thread overview]
Message-ID: <20060706233909.GN1316@us.ibm.com> (raw)
In-Reply-To: <1152226204.21787.2093.camel@stark>
On Thu, Jul 06, 2006 at 03:50:03PM -0700, Matt Helsley wrote:
> On Thu, 2006-07-06 at 16:28 -0400, Alan Stern wrote:
> > I've been trying to come up with a way to allow SRCU structures to be
> > initialized statically rather than dynamically. The per-cpu data makes it
> > quite hard. Not only do you have to use different routines to access
> > static vs. dynamic per-cpu data, there's just no good way to write a
> > static initializer. This is because the per-cpu data requires its own
> > separate definition, and there's no way to call DEFINE_PER_CPU from within
> > an initializer.
> >
> > Here, in outline, is the best I've been able to come up with. It uses a
> > function pointer member to select the appropriate sort of per-cpu data
> > access. You would use it like this:
> >
> > PREDEFINE_SRCU(s);
> > static DEFINE_SRCU(s);
> > ...
> > idx = srcu_read_lock(&s);
> > ... etc ...
> >
> > Alternative possibilities involve an entire parallel implementation for
> > statically-initialized structures (which seems excessive) or using a
> > runtime test instead of a function pointer to select the dereferencing
> > mechanism.
> >
> > Can anybody suggest anything better?
> >
> > Alan Stern
>
> I started to come up with something similar but did not get as far. I
> suspect the runtime test you're suggesting would look like:
>
> #include <asm/sections.h>
>
> ...
> if ((per_cpu_ptr >= __per_cpu_start) && (per_cpu_ptr < __per_cpu_end)) {
> /* staticly-allocated per-cpu data */
> ...
> } else {
> /* dynamically-allocated per-cpu data */
> ...
> }
> ...
>
> I think that's easier to read and understand than following a function
> pointer.
Is this what the two of you are getting at?
#define DEFINE_SRCU_STRUCT(name) \
DEFINE_PER_CPU(struct srcu_struct_array, name) = { 0, 0 }; \
struct srcu_struct name = { \
.completed = 0, \
.per_cpu_ref = NULL, \
.mutex = __MUTEX_INITIALIZER(name.mutex) \
}
#define srcu_read_lock(ss) \
({ \
if ((ss)->per_cpu_ref != NULL) \
srcu_read_lock_dynamic(&ss); \
else { \
int ret; \
\
preempt_disable(); \
ret = srcu_read_lock_static(&ss, &__get_cpu_var(ss)); \
preempt_enable(); \
ret; \
} \
})
int srcu_read_lock_dynamic(struct srcu_struct *sp)
{
int idx;
preempt_disable();
idx = sp->completed & 0x1;
barrier(); /* ensure compiler looks -once- at sp->completed. */
per_cpu_ptr(sp->per_cpu_ref, smp_processor_id())->c[idx]++;
srcu_barrier(); /* ensure compiler won't misorder critical section. */
preempt_enable();
return idx;
}
int srcu_read_lock_static(struct srcu_struct *sp, srcu_struct_array *cp)
{
int idx;
idx = sp->completed & 0x1;
barrier(); /* ensure compiler looks -once- at sp->completed. */
cp->c[idx]++;
srcu_barrier(); /* ensure compiler won't misorder critical section. */
return idx;
}
And similarly for srcu_read_unlock()?
I sure hope that there is a better way!!! For one thing, you cannot pass
a pointer in to srcu_read_lock(), since __get_cpu_var's name mangling would
fail in that case...
Thanx, Paul
next parent reply other threads:[~2006-07-07 0:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.44L0.0607061603320.5768-100000@iolanthe.rowland.org>
[not found] ` <1152226204.21787.2093.camel@stark>
2006-07-06 23:39 ` Paul E. McKenney [this message]
[not found] ` <Pine.LNX.4.44L0.0607071051430.17135-100000@iolanthe.rowland.org>
2006-07-07 16:33 ` [PATCH 1/2] srcu-3: RCU variant permitting read-side blocking Paul E. McKenney
[not found] ` <Pine.LNX.4.44L0.0607071345270.6793-100000@iolanthe.rowland.org>
2006-07-07 18:59 ` Paul E. McKenney
2006-07-07 19:59 ` Alan Stern
2006-07-07 21:11 ` Matt Helsley
2006-07-07 21:47 ` Paul E. McKenney
2006-07-10 19:11 ` SRCU-based notifier chains Alan Stern
2006-07-11 17:39 ` Paul E. McKenney
2006-07-11 18:03 ` Alan Stern
2006-07-11 18:22 ` Paul E. McKenney
2006-07-11 18:18 ` [PATCH] Add " Alan Stern
2006-07-11 18:30 ` Paul E. McKenney
2006-07-12 0:56 ` Chandra Seetharaman
[not found] <20060711172530.GA93@oleg>
2006-07-11 14:56 ` [PATCH 1/2] srcu-3: RCU variant permitting read-side blocking Alan Stern
2006-07-11 18:21 ` Paul E. McKenney
2006-07-06 17:14 [PATCH 0/2] srcu-3: add RCU variant that permits " Paul E. McKenney
2006-07-06 17:20 ` [PATCH 1/2] srcu-3: RCU variant permitting " Paul E. McKenney
[not found] ` <20060709235029.GA194@oleg>
2006-07-10 16:51 ` Paul E. McKenney
[not found] ` <44B29212.1070301@yahoo.com.au>
2006-07-11 14:19 ` 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=20060706233909.GN1316@us.ibm.com \
--to=paulmck@us.ibm.com \
--cc=akpm@osdl.org \
--cc=dipankar@in.ibm.com \
--cc=dvhltc@us.ibm.com \
--cc=jes@sgi.com \
--cc=linux-kernel@us.ibm.com \
--cc=matthltc@us.ibm.com \
--cc=mingo@elte.hu \
--cc=oleg@tv-sign.ru \
--cc=stern@rowland.harvard.edu \
--cc=tytso@us.ibm.com \
/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