From: Oleg Nesterov <oleg@tv-sign.ru>
To: "Paul E. McKenney" <paulmck@us.ibm.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] srcu: RCU variant permitting read-side blocking
Date: Wed, 28 Jun 2006 01:13:58 +0400 [thread overview]
Message-ID: <20060627211358.GA484@oleg> (raw)
Hello Paul,
"Paul E. McKenney" wrote:
>
> +void init_srcu_struct(struct srcu_struct *sp)
> +{
> + int cpu;
> +
> + sp->completed = 0;
> + sp->per_cpu_ref = (struct srcu_struct_array *)
> + kmalloc(NR_CPUS * sizeof(*sp->per_cpu_ref),
> + GFP_KERNEL);
> + for_each_cpu(cpu) {
> + sp->per_cpu_ref[cpu].c[0] = 0;
> + sp->per_cpu_ref[cpu].c[1] = 0;
> + }
Isn't it simpler to just do:
sp->per_cpu_ref = kzmalloc(NR_CPUS * sizeof(*sp->per_cpu_ref),
GFP_KERNEL);
and drop 'for_each_cpu(cpu)' initialization ?
> +int srcu_read_lock(struct srcu_struct *sp)
> +{
> + int idx;
> +
> + preempt_disable();
> + idx = sp->completed & 0x1;
> + barrier();
> + sp->per_cpu_ref[smp_processor_id()].c[idx]++;
> + preempt_enable();
> + return idx;
> +}
Could you explain this 'barrier()' ?
> +void synchronize_srcu(struct srcu_struct *sp)
> +{
> + int cpu;
> + int idx;
> + int sum;
> +
> + might_sleep();
> +
> + mutex_lock(&sp->mutex);
> +
> + smp_mb(); /* Prevent operations from leaking in. */
Why smp_wmb() is not enough? We are doing synchronize_sched() below
before reading ->per_cpu_ref, and ->completed is protected by ->mutex.
> + idx = sp->completed & 0x1;
> + sp->completed++;
But srcu_read_lock()'s path and rcu_dereference() doesn't have rmb(),
and the reader can block, so I can't understand how this all works.
Suppose ->completed == 0,
WRITER: READER:
old = global_ptr;
rcu_assign_pointer(global_ptr, new);
synchronize_srcu:
locks mutex, does mb,
->completed++;
srcu_read_lock();
// reads ->completed == 1
// does .c[1]++
ptr = rcu_dereference(global_ptr)
// reads the *OLD* value,
// because we don't have rmb()
block_on_something();
synchronize_sched();
// ... still blocked ...
checks sum_of(.c[0]) == 0, yes
synchronize_sched();
// ... still blocked ...
kfree(old);
// wake up
do_something(ptr);
Also, I can't understand the purpose of 2-nd synchronize_sched() in
synchronize_srcu().
Please help!
Oleg.
next reply other threads:[~2006-06-27 16:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-27 21:13 Oleg Nesterov [this message]
2006-06-27 18:59 ` [PATCH 1/2] srcu: RCU variant permitting read-side blocking Paul E. McKenney
2006-06-27 19:19 ` Paul E. McKenney
2006-06-28 19:41 ` Oleg Nesterov
2006-06-28 15:32 ` Paul E. McKenney
[not found] <20060626190328.GD2141@us.ibm.com>
[not found] ` <20060626190743.GE2141@us.ibm.com>
[not found] ` <20060626134447.a75cb385.akpm@osdl.org>
[not found] ` <20060627005350.GG1295@us.ibm.com>
[not found] ` <20060626181418.70aeffd3.akpm@osdl.org>
2006-06-27 1:37 ` 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=20060627211358.GA484@oleg \
--to=oleg@tv-sign.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@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