From: "Paul E. McKenney" <paulmck@us.ibm.com>
To: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Jens Axboe <jens.axboe@oracle.com>,
linux-kernel@vger.kernel.org
Subject: Re: [patch] cpufreq: mark cpufreq_tsc() as core_initcall_sync
Date: Sun, 26 Nov 2006 21:02:48 -0800 [thread overview]
Message-ID: <20061127050247.GC5021@us.ibm.com> (raw)
In-Reply-To: <20061124182153.GA9868@oleg>
On Fri, Nov 24, 2006 at 09:21:53PM +0300, Oleg Nesterov wrote:
> Ok, synchronize_xxx() passed 1 hour rcutorture test on dual P-III.
>
> It behaves the same as srcu but optimized for writers. The fast path
> for synchronize_xxx() is mutex_lock() + atomic_read() + mutex_unlock().
> The slow path is __wait_event(), no polling. However, the reader does
> atomic inc/dec on lock/unlock, and the counters are not per-cpu.
>
> Jens, is it ok for you? Alan, Paul, what is your opinion?
Looks pretty good, actually. A few quibbles below. I need to review
again after sleeping on it.
Thanx, Paul
> Oleg.
>
> --- 19-rc6/kernel/__rcutorture.c 2006-11-17 19:42:31.000000000 +0300
> +++ 19-rc6/kernel/rcutorture.c 2006-11-24 21:00:00.000000000 +0300
> @@ -464,6 +464,120 @@ static struct rcu_torture_ops srcu_ops =
> .name = "srcu"
> };
>
> +//-----------------------------------------------------------------------------
> +struct xxx_struct {
> + int completed;
> + atomic_t ctr[2];
> + struct mutex mutex;
> + wait_queue_head_t wq;
> +};
> +
> +void init_xxx_struct(struct xxx_struct *sp)
> +{
> + sp->completed = 0;
> + atomic_set(sp->ctr + 0, 1);
> + atomic_set(sp->ctr + 1, 0);
> + mutex_init(&sp->mutex);
> + init_waitqueue_head(&sp->wq);
> +}
> +
> +int xxx_read_lock(struct xxx_struct *sp)
> +{
> + for (;;) {
> + int idx = sp->completed & 0x1;
Might need a comment saying why no rcu_dereference() needed on the
preceding line. The reason (as I understand it) is that we are
only doing atomic operations on the element being indexed. Is there
an Alpha architect in the house? ;-)
> + if (likely(atomic_inc_not_zero(sp->ctr + idx)))
> + return idx;
> + }
> +}
The loop seems absolutely necessary if one wishes to avoid a
synchronize_sched() in synchronize_xxx() below (and was one of the things
I was missing earlier). However, isn't there a possibility that a pile
of synchronize_xxx() calls might indefinitely delay an unlucky reader?
> +
> +void xxx_read_unlock(struct xxx_struct *sp, int idx)
> +{
> + if (unlikely(atomic_dec_and_test(sp->ctr + idx)))
> + wake_up(&sp->wq);
> +}
> +
> +void synchronize_xxx(struct xxx_struct *sp)
> +{
> + int idx;
> +
> + mutex_lock(&sp->mutex);
> +
> + idx = sp->completed & 0x1;
> + if (!atomic_add_unless(sp->ctr + idx, -1, 1))
> + goto out;
> +
> + atomic_inc(sp->ctr + (idx ^ 0x1));
> + sp->completed++;
> +
> + __wait_event(sp->wq, !atomic_read(sp->ctr + idx));
> +out:
> + mutex_unlock(&sp->mutex);
> +}
Test code!!! Very good!!! (This is added to rcutorture, right?)
> +//-----------------------------------------------------------------------------
> +static struct xxx_struct xxx_ctl;
> +
> +static void xxx_torture_init(void)
> +{
> + init_xxx_struct(&xxx_ctl);
> + rcu_sync_torture_init();
> +}
> +
> +static void xxx_torture_cleanup(void)
> +{
> + synchronize_xxx(&xxx_ctl);
> +}
> +
> +static int xxx_torture_read_lock(void)
> +{
> + return xxx_read_lock(&xxx_ctl);
> +}
> +
> +static void xxx_torture_read_unlock(int idx)
> +{
> + xxx_read_unlock(&xxx_ctl, idx);
> +}
> +
> +static int xxx_torture_completed(void)
> +{
> + return xxx_ctl.completed;
> +}
> +
> +static void xxx_torture_synchronize(void)
> +{
> + synchronize_xxx(&xxx_ctl);
> +}
> +
> +static int xxx_torture_stats(char *page)
> +{
> + int cnt = 0;
> + int idx = xxx_ctl.completed & 0x1;
> +
> + cnt += sprintf(&page[cnt], "%s%s per-CPU(idx=%d):",
> + torture_type, TORTURE_FLAG, idx);
> +
> + cnt += sprintf(&page[cnt], " (%d,%d)",
> + atomic_read(xxx_ctl.ctr + 0),
> + atomic_read(xxx_ctl.ctr + 1));
> +
> + cnt += sprintf(&page[cnt], "\n");
> + return cnt;
> +}
> +
> +static struct rcu_torture_ops xxx_ops = {
> + .init = xxx_torture_init,
> + .cleanup = xxx_torture_cleanup,
> + .readlock = xxx_torture_read_lock,
> + .readdelay = srcu_read_delay,
> + .readunlock = xxx_torture_read_unlock,
> + .completed = xxx_torture_completed,
> + .deferredfree = rcu_sync_torture_deferred_free,
> + .sync = xxx_torture_synchronize,
> + .stats = xxx_torture_stats,
> + .name = "xxx"
> +};
> +//-----------------------------------------------------------------------------
> +
> /*
> * Definitions for sched torture testing.
> */
> @@ -503,8 +617,8 @@ static struct rcu_torture_ops sched_ops
> };
>
> static struct rcu_torture_ops *torture_ops[] =
> - { &rcu_ops, &rcu_sync_ops, &rcu_bh_ops, &rcu_bh_sync_ops, &srcu_ops,
> - &sched_ops, NULL };
> + { &rcu_ops, &rcu_sync_ops, &rcu_bh_ops, &rcu_bh_sync_ops,
> + &srcu_ops, &xxx_ops, &sched_ops, NULL };
>
> /*
> * RCU torture writer kthread. Repeatedly substitutes a new structure
>
next prev parent reply other threads:[~2006-11-27 5:07 UTC|newest]
Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-16 20:00 BUG: cpufreq notification broken Thomas Gleixner
2006-11-16 20:15 ` [patch] cpufreq: mark cpufreq_tsc() as core_initcall_sync Ingo Molnar
2006-11-16 20:45 ` Thomas Gleixner
2006-11-16 21:47 ` Linus Torvalds
2006-11-16 22:03 ` Alan Stern
2006-11-16 22:21 ` Linus Torvalds
2006-11-17 3:06 ` Alan Stern
2006-11-17 6:51 ` Paul E. McKenney
2006-11-17 9:29 ` Jens Axboe
2006-11-17 18:39 ` Oleg Nesterov
2006-11-18 0:28 ` Paul E. McKenney
2006-11-18 16:15 ` Alan Stern
2006-11-18 17:14 ` Paul E. McKenney
2006-11-18 19:34 ` Oleg Nesterov
2006-11-19 21:26 ` Paul E. McKenney
2006-11-18 21:00 ` Alan Stern
2006-11-18 21:25 ` Oleg Nesterov
2006-11-18 22:13 ` Alan Stern
2006-11-18 22:46 ` Oleg Nesterov
2006-11-19 20:12 ` Alan Stern
2006-11-19 21:43 ` Paul E. McKenney
2006-11-20 17:19 ` Alan Stern
2006-11-20 17:58 ` Jens Axboe
2006-11-20 19:39 ` Alan Stern
2006-11-20 20:13 ` Jens Axboe
2006-11-20 21:39 ` Alan Stern
2006-11-21 7:39 ` Jens Axboe
2006-11-20 18:57 ` Oleg Nesterov
2006-11-20 20:01 ` Alan Stern
2006-11-20 20:51 ` Paul E. McKenney
2006-11-21 20:04 ` Oleg Nesterov
2006-11-21 20:54 ` Alan Stern
2006-11-21 22:07 ` Paul E. McKenney
2006-11-20 20:38 ` Paul E. McKenney
2006-11-21 16:44 ` Oleg Nesterov
2006-11-21 19:56 ` Paul E. McKenney
2006-11-21 20:26 ` Alan Stern
2006-11-21 23:03 ` Paul E. McKenney
2006-11-22 2:17 ` Alan Stern
2006-11-22 17:01 ` Paul E. McKenney
2006-11-26 22:25 ` Oleg Nesterov
2006-11-27 21:10 ` Alan Stern
2006-11-28 1:47 ` Paul E. McKenney
2006-11-20 19:17 ` Paul E. McKenney
2006-11-20 20:22 ` Alan Stern
2006-11-21 17:55 ` Paul E. McKenney
2006-11-21 17:56 ` Alan Stern
2006-11-21 19:13 ` Paul E. McKenney
2006-11-21 20:40 ` Alan Stern
2006-11-22 18:08 ` Paul E. McKenney
2006-11-21 21:01 ` Oleg Nesterov
2006-11-22 0:51 ` Paul E. McKenney
2006-11-18 18:46 ` Oleg Nesterov
2006-11-19 21:07 ` Paul E. McKenney
2006-11-20 7:15 ` Jens Axboe
2006-11-20 16:59 ` Paul E. McKenney
2006-11-20 17:55 ` Jens Axboe
2006-11-20 20:09 ` Paul E. McKenney
2006-11-20 20:21 ` Jens Axboe
2006-11-18 19:02 ` Oleg Nesterov
2006-11-19 21:23 ` Paul E. McKenney
2006-11-17 19:15 ` Paul E. McKenney
2006-11-17 19:27 ` Alan Stern
2006-11-18 0:38 ` Paul E. McKenney
2006-11-18 4:33 ` Alan Stern
2006-11-18 4:51 ` Andrew Morton
2006-11-18 5:57 ` Paul E. McKenney
2006-11-19 19:00 ` Oleg Nesterov
2006-11-19 20:21 ` Alan Stern
2006-11-19 20:55 ` Oleg Nesterov
2006-11-19 21:09 ` Alan Stern
2006-11-19 21:17 ` Oleg Nesterov
2006-11-19 21:54 ` Paul E. McKenney
2006-11-19 22:28 ` Oleg Nesterov
2006-11-20 5:47 ` Paul E. McKenney
2006-11-19 21:20 ` Paul E. McKenney
2006-11-19 21:50 ` Oleg Nesterov
2006-11-19 22:04 ` Paul E. McKenney
2006-11-23 14:59 ` Oleg Nesterov
2006-11-23 20:40 ` Paul E. McKenney
2006-11-23 21:34 ` Oleg Nesterov
2006-11-23 21:49 ` Oleg Nesterov
2006-11-27 4:33 ` Paul E. McKenney
2006-11-24 18:21 ` Oleg Nesterov
2006-11-24 20:04 ` Jens Axboe
2006-11-24 20:47 ` Alan Stern
2006-11-24 21:13 ` Oleg Nesterov
2006-11-25 3:24 ` Alan Stern
2006-11-25 17:14 ` Oleg Nesterov
2006-11-25 22:06 ` Alan Stern
2006-11-26 21:34 ` Oleg Nesterov
2006-11-27 5:02 ` Paul E. McKenney [this message]
2006-11-27 16:11 ` Oleg Nesterov
2006-11-27 16:56 ` Oleg Nesterov
2006-11-29 19:29 ` Paul E. McKenney
2006-11-29 20:16 ` Oleg Nesterov
2006-11-29 23:08 ` Paul E. McKenney
2006-11-30 0:01 ` Oleg Nesterov
2006-11-17 2:33 ` Paul E. McKenney
2006-11-16 20:52 ` Peter Zijlstra
2006-11-16 21:20 ` Andrew Morton
2006-11-16 21:27 ` Thomas Gleixner
2006-11-20 19:57 ` Linus Torvalds
2006-11-16 20:27 ` BUG: cpufreq notification broken Alan Stern
2006-11-16 21:09 ` Thomas Gleixner
2006-11-16 21:26 ` Alan Stern
2006-11-16 21:36 ` Thomas Gleixner
2006-11-16 21:56 ` Alan Stern
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=20061127050247.GC5021@us.ibm.com \
--to=paulmck@us.ibm.com \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@tv-sign.ru \
--cc=stern@rowland.harvard.edu \
/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
Powered by JetHome