From: Oleg Nesterov <oleg@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>,
Peter Zijlstra <peterz@infradead.org>,
Mel Gorman <mgorman@suse.de>, Rik van Riel <riel@redhat.com>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
Ingo Molnar <mingo@kernel.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Thomas Gleixner <tglx@linutronix.de>,
Steven Rostedt <rostedt@goodmis.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/5] rcusync: introduce struct rcu_sync_ops
Date: Fri, 4 Oct 2013 21:22:12 +0200 [thread overview]
Message-ID: <20131004192212.GA18472@redhat.com> (raw)
In-Reply-To: <CA+55aFxfbV2AsOUhL318AH8y4BUe2FXFb8aTFuqPqc_2SdV2MA@mail.gmail.com>
On 10/04, Linus Torvalds wrote:
>
> On Fri, Oct 4, 2013 at 11:46 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> > Add the new struct rcu_sync_ops which holds sync/call methods, and
> > turn the function pointers in rcu_sync_struct into the single pointer
> > to struct rcu_sync_ops.
> >
> > +struct rcu_sync_ops {
> > + void (*sync)(void);
> > + void (*call)(struct rcu_head *, void (*)(struct rcu_head *));
> > +};
> > +
> > struct rcu_sync_struct {
> > int gp_state;
> > int gp_count;
> > @@ -12,43 +17,9 @@ struct rcu_sync_struct {
> > int cb_state;
> > struct rcu_head cb_head;
> >
> > - void (*sync)(void);
> > - void (*call)(struct rcu_head *, void (*)(struct rcu_head *));
> > + struct rcu_sync_ops *ops;
>
> Ugh.
>
> This interface pretty much guarantees that a compiler can never do
> anything clever, like know that "hey, you used a static initializer on
> this thing, and the fields are const, so now know statically what the
> functions are, and I can just turn the indirect jumps into direct
> jumps".
But we do not care? rcu_sync_struct->ops is only used by the writer
(slow path). In this case the simpler the better, I think.
> - instead, use a "static const" type descriptor for each type (it
> approaches being your "rcu_sync_ops" structure). Pass this in as an
> argument to all the functions (use a #define per type or something, so
> that users don't need to do this by hand)
>
> - now every single user passes in that type descriptor.
>
> - together with using a few inline functions, suddenly the "indirect"
> jumps through this type descriptor end up actually being nice direct
> compile-time constants: iow, they get turned into direct jumps.
Hmm. Can't understand, sorry... Could you spell??
I assume you do not suggest to pass the "type" to, say, rcu_sync_enter?
Oleg.
next prev parent reply other threads:[~2013-10-04 19:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-04 18:46 [PATCH 0/5] rcusync: validations + dtor + exclusive Oleg Nesterov
2013-10-04 18:46 ` [PATCH 1/5] rcusync: introduce struct rcu_sync_ops Oleg Nesterov
2013-10-04 19:12 ` Linus Torvalds
2013-10-04 19:22 ` Oleg Nesterov [this message]
2013-10-04 19:30 ` Steven Rostedt
2013-10-04 19:38 ` Linus Torvalds
2013-10-04 19:42 ` Peter Zijlstra
2013-10-05 17:21 ` Oleg Nesterov
2013-10-05 17:17 ` Oleg Nesterov
2013-10-08 9:13 ` Peter Zijlstra
2013-10-08 15:33 ` Oleg Nesterov
2013-10-08 16:34 ` Paul E. McKenney
2013-10-04 18:46 ` [PATCH 2/5] rcusync: add the CONFIG_PROVE_RCU checks Oleg Nesterov
2013-10-04 18:46 ` [PATCH 3/5] rcusync: introduce rcu_sync_dtor() Oleg Nesterov
2013-10-04 18:46 ` [PATCH 4/5] rcusync: introduce rcu_sync_struct->exclusive mode Oleg Nesterov
2013-10-04 19:29 ` Peter Zijlstra
2013-10-04 19:56 ` Oleg Nesterov
2013-10-04 20:41 ` Peter Zijlstra
2013-10-06 13:22 ` Oleg Nesterov
2013-10-07 10:49 ` Peter Zijlstra
2013-10-04 18:46 ` [PATCH 5/5] rcusync: make rcu_sync_enter() return "bool" Oleg Nesterov
2013-10-04 19:32 ` [PATCH 0/5] rcusync: validations + dtor + exclusive Peter Zijlstra
2013-10-04 21:28 ` Paul E. McKenney
2013-10-05 17:22 ` Oleg Nesterov
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=20131004192212.GA18472@redhat.com \
--to=oleg@redhat.com \
--cc=aarcange@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=rostedt@goodmis.org \
--cc=srikar@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.