From: "Paul E. McKenney" <paulmck@us.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org, Esben Nielsen <simlo@phys.au.dk>
Subject: Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07
Date: Wed, 23 Mar 2005 22:06:17 -0800 [thread overview]
Message-ID: <20050324060617.GB1298@us.ibm.com> (raw)
In-Reply-To: <20050323063727.GA32199@elte.hu>
On Wed, Mar 23, 2005 at 07:37:27AM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <mingo@elte.hu> wrote:
>
> > the 'migrate read count' solution seems more promising, as it would
> > keep other parts of the RCU code unchanged. [ But it seems to break
> > the nice 'flip pointers' method you found to force a grace period. If
> > a 'read section' can migrate from one CPU to another then it can
> > migrate back as well, at which point it cannot have the 'old' pointer.
> > Maybe it would still work better than no flip pointers. ]
>
> the flip pointer method could be made to work if we had a NR_CPUS array
> of 'current RCU pointer' values attached to the task - and that array
> would be cleared if the task exits the read section. But this has memory
> usage worries with large NR_CPUS. (full clearing of the array can be
> avoided by using some sort of 'read section generation' counter attached
> to each pointer)
The only per-task data you need to maintain is a single pointer to
the per-CPU counter that was incremented by the outermost rcu_read_lock().
You also need a global index, call it "rcu_current_ctr_set" (or come
up with a better name!) along with a per-CPU pair of counters:
struct rcu_ctr_set { /* or maybe there is a way to drop array */
atomic_t ctr[2]; /* into DECLARE_PER_CPU() without a struct */
} /* wrapper... */
int rcu_curset = 0;
DEFINE_PER_CPU(struct rcu_ctr_set, rcu_ctr_set) = { 0, 0 };
You need two fields in the task structure:
atomic_t *rcu_preempt_ctr;
int rcu_nesting;
Then you have something like:
void rcu_read_lock(void)
{
if (current->rcu_nesting++ == 0) {
preempt_disable();
current->rcu_preempt_ctr =
&__get_cpu_var(rcu_ctr_set).ctr[rcu_curset];
atomic_inc(current->rcu_preempt_ctr);
preempt_enable();
smp_mb();
}
}
void rcu_read_unlock(void)
{
if (--current->rcu_nesting == 0) {
smb_mb(); /* might only need smp_wmb()... */
atomic_dec(current->rcu_preempt_ctr);
current->rcu_preempt_ctr = NULL; /* for debug */
}
}
One can then force a grace period via something like the following,
but only if you know that all of the rcu_ctr_set.ctr[!current] are zero:
void _synchronize_kernel(void)
{
int cpu;
spin_lock(&rcu_mutex);
rcu_curset = !rcu_curset;
for (;;) {
for_each_cpu(cpu) {
if (atomic_read(&__get_cpu_var(rcu_ctr_set).ctr[!rcu_curset]) != 0) {
/* yield CPU for a bit */
continue;
}
}
}
spin_unlock(&rcu_mutex);
}
In real life, you need a way to multiplex multiple calls to
_synchronize_kernel() into a single counter-flip event, by
setting up callbacks. And so on...
The above stolen liberally from your patch and from my memories of
Dipankar's RCU patch for CONFIG_PREEMPT kernels. Guaranteed to have
horrible bugs. ;-)
Thanx, Paul
next prev parent reply other threads:[~2005-03-24 6:08 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-19 19:16 [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00 Ingo Molnar
2005-03-20 0:24 ` Lee Revell
2005-03-21 15:42 ` K.R. Foley
2005-03-20 1:33 ` Lee Revell
2005-03-20 1:50 ` K.R. Foley
2005-03-20 4:32 ` Lee Revell
2005-03-20 22:40 ` Paul E. McKenney
2005-03-20 17:45 ` Paul E. McKenney
2005-03-21 8:53 ` Ingo Molnar
2005-03-21 9:01 ` Ingo Molnar
2005-03-21 9:06 ` [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-01 Ingo Molnar
2005-03-21 23:10 ` Magnus Naeslund(t)
2005-03-22 5:40 ` Paul E. McKenney
2005-03-22 8:50 ` Ingo Molnar
2005-03-22 13:56 ` Magnus Naeslund(t)
2005-03-23 5:46 ` Paul E. McKenney
2005-03-22 5:43 ` Paul E. McKenney
2005-03-22 7:24 ` Ingo Molnar
2005-03-22 9:23 ` Ingo Molnar
2005-03-22 9:32 ` Ingo Molnar
2005-03-22 10:01 ` [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-05 Ingo Molnar
2005-03-22 11:28 ` [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07 Ingo Molnar
2005-03-22 15:06 ` K.R. Foley
2005-03-22 18:05 ` Magnus Naeslund(t)
2005-03-23 6:16 ` Paul E. McKenney
2005-03-23 6:33 ` Ingo Molnar
2005-03-23 6:37 ` Ingo Molnar
2005-03-24 6:06 ` Paul E. McKenney [this message]
2005-03-23 7:16 ` Ingo Molnar
2005-03-23 7:54 ` Steven Rostedt
2005-03-23 7:58 ` Ingo Molnar
2005-03-23 8:29 ` Peter Zijlstra
2005-03-23 9:03 ` Ingo Molnar
2005-03-24 6:45 ` Paul E. McKenney
2005-03-23 21:46 ` Ingo Molnar
2005-03-24 6:59 ` Paul E. McKenney
2005-03-24 6:38 ` Paul E. McKenney
2005-03-23 9:38 ` Herbert Xu
2005-03-23 9:49 ` Herbert Xu
2005-03-24 6:52 ` Paul E. McKenney
2005-03-24 5:28 ` Paul E. McKenney
2005-03-24 5:34 ` Ingo Molnar
2005-03-24 7:46 ` Paul E. McKenney
2005-03-24 8:31 ` Steven Rostedt
2005-03-24 8:47 ` Steven Rostedt
2005-03-24 10:45 ` Ingo Molnar
2005-03-24 11:39 ` Ingo Molnar
2005-03-24 14:33 ` Steven Rostedt
2005-03-24 17:51 ` Ingo Molnar
2005-03-24 18:17 ` Ingo Molnar
2005-03-24 23:05 ` Esben Nielsen
2005-03-25 6:19 ` Ingo Molnar
2005-03-26 16:31 ` Steven Rostedt
2005-03-26 19:11 ` Ingo Molnar
2005-03-26 16:04 ` Steven Rostedt
2005-03-30 6:31 ` Steven Rostedt
2005-03-30 6:50 ` Ingo Molnar
2005-03-30 16:46 ` Steven Rostedt
2005-03-30 19:44 ` Esben Nielsen
2005-03-30 19:56 ` Steven Rostedt
2005-03-30 21:39 ` Steven Rostedt
2005-03-30 21:43 ` Steven Rostedt
2005-03-31 11:03 ` Ingo Molnar
2005-03-31 12:03 ` Esben Nielsen
2005-03-31 12:14 ` Steven Rostedt
2005-03-31 13:33 ` Ingo Molnar
2005-03-31 12:22 ` Steven Rostedt
2005-03-31 12:36 ` Steven Rostedt
2005-03-31 12:58 ` Steven Rostedt
2005-03-31 13:28 ` Ingo Molnar
2005-03-31 12:49 ` Steven Rostedt
2005-03-31 14:10 ` Ingo Molnar
2005-03-31 17:41 ` Steven Rostedt
2005-03-31 17:49 ` Ingo Molnar
2005-03-31 18:17 ` Gene Heskett
2005-03-31 21:00 ` [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07 (update) Gene Heskett
2005-03-31 20:22 ` [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07 Steven Rostedt
2005-04-01 0:59 ` Steven Rostedt
2005-04-01 4:43 ` Ingo Molnar
2005-04-01 5:13 ` Steven Rostedt
2005-04-01 5:19 ` Ingo Molnar
2005-04-01 12:27 ` Steven Rostedt
2005-04-07 21:21 ` Steven Rostedt
2005-04-10 10:31 ` Ingo Molnar
2005-04-10 15:06 ` Steven Rostedt
2005-03-24 10:42 ` Ingo Molnar
2005-03-23 9:40 ` Herbert Xu
2005-03-23 9:48 ` Herbert Xu
2005-03-23 5:23 ` [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-05 Paul E. McKenney
2005-03-23 4:48 ` [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-01 Paul E. McKenney
2005-03-23 6:21 ` Ingo Molnar
2005-03-22 8:59 ` Ingo Molnar
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=20050324060617.GB1298@us.ibm.com \
--to=paulmck@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=simlo@phys.au.dk \
/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