On Mon, Mar 02, 2015 at 10:24:40AM +0100, Peter Zijlstra wrote:
> On Sat, Feb 28, 2015 at 03:32:03PM -0800, Paul E. McKenney wrote:
> > Whew!
> >
> > Though otherwise whatever you were doing would have been pretty cool
> > and fun to learn about. ;-)
>
> So I think I can do that; where readers a
On Sat, Feb 28, 2015 at 03:32:03PM -0800, Paul E. McKenney wrote:
> Whew!
>
> Though otherwise whatever you were doing would have been pretty cool
> and fun to learn about. ;-)
So I think I can do that; where readers and writers are fully separated,
but it requires:
- tripple latch
- copy ope
On Sat, Feb 28, 2015 at 05:56:54PM +0100, Peter Zijlstra wrote:
> On Sat, Feb 28, 2015 at 05:41:12PM +0100, Peter Zijlstra wrote:
> > > > > + rb_link_node(&mn->node, parent, link);
> > > >
> > > > This makes the new module visible to readers, if I understand correctly.
> > >
> > > You do.
> >
On Fri, Feb 27, 2015 at 11:01:14AM +0100, Peter Zijlstra wrote:
> On Thu, Feb 26, 2015 at 11:41:44AM -0800, Paul E. McKenney wrote:
> > > As per the above argument; without doing the whole READ/WRITE_ONCE for
> > > the rb tree primitives, I think we're fine. We don't actually need the
> > > read_ba
On Sat, Feb 28, 2015 at 05:41:12PM +0100, Peter Zijlstra wrote:
> > > > + rb_link_node(&mn->node, parent, link);
> > >
> > > This makes the new module visible to readers, if I understand correctly.
> >
> > You do.
>
> I think I have reconsidered; this does not in fact make it visible.
Ah;
On Thu, Feb 26, 2015 at 08:13:35PM +0100, Peter Zijlstra wrote:
> > > +static void __tree_insert(struct latch_tree_root *mod_tree, struct
> > > module *mod, int idx)
> > > +{
> > > + struct rb_root *root = &mod_tree->tree[idx & latch_bit];
> > > + struct module_node *mn = &mod->tree_node[idx];
> >
On Fri, Feb 27, 2015 at 10:32:39PM +1030, Rusty Russell wrote:
> Peter Zijlstra writes:
> > One of the users of this is __kernel_text_address() which is employed in
> > many stack unwinders; which in turn are used by perf-callchain (possibly
> > from NMI context).
>
> Um, so the stack unwinders u
Peter Zijlstra writes:
> One of the users of this is __kernel_text_address() which is employed in
> many stack unwinders; which in turn are used by perf-callchain (possibly
> from NMI context).
Um, so the stack unwinders use "does this look like a kernel address"
because we omit the frame pointer
Peter Zijlstra writes:
> On Thu, Feb 26, 2015 at 12:43:09PM +0100, Peter Zijlstra wrote:
>
> Assuming struct module is cacheline aligned, Rusty? from what I can find
> its squirreled away in some data structure:
>
> mod = (void *)info->sechdrs[info->index.mod].sh_addr
>
> And I can't seem to qui
On Thu, Feb 26, 2015 at 11:41:44AM -0800, Paul E. McKenney wrote:
> > As per the above argument; without doing the whole READ/WRITE_ONCE for
> > the rb tree primitives, I think we're fine. We don't actually need the
> > read_barrier_depends() I think.
> >
> > I think this because raw_read_seqcount
On Thu, Feb 26, 2015 at 12:52:16PM -0800, Andi Kleen wrote:
> >
> > Thoughts?
>
> Just use my original patch using page tables which did not need any of these
> research projects.
Hey, some people actually like to think! And the benefit is that all
archs get a win.
--
To unsubscribe from this li
On Thu, Feb 26, 2015 at 08:45:16PM +0100, Peter Zijlstra wrote:
> On Thu, Feb 26, 2015 at 11:41:44AM -0800, Paul E. McKenney wrote:
> > Or just have the *_ONCE() calls in the single version. I bet that there
> > is no visible performance loss.
>
> I'll go play with that tomorrow, see what GCC mak
>
> Thoughts?
Just use my original patch using page tables which did not need any of these
research projects.
http://www.serverphorums.com/read.php?12,1043794,1043796#msg-1043796
-Andi
--
a...@linux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubs
On Thu, Feb 26, 2015 at 11:41:44AM -0800, Paul E. McKenney wrote:
> Or just have the *_ONCE() calls in the single version. I bet that there
> is no visible performance loss.
I'll go play with that tomorrow, see what GCC makes of it.
--
To unsubscribe from this list: send the line "unsubscribe lin
On Thu, Feb 26, 2015 at 08:13:35PM +0100, Peter Zijlstra wrote:
> On Thu, Feb 26, 2015 at 10:28:17AM -0800, Paul E. McKenney wrote:
>
>
> > Color me confused, both by the existing code and the modifications.
> >
> > It appears that you are using seqlock to force readers to retry when
> > a concu
On Thu, Feb 26, 2015 at 10:28:17AM -0800, Paul E. McKenney wrote:
> Color me confused, both by the existing code and the modifications.
>
> It appears that you are using seqlock to force readers to retry when
> a concurrent update occurs, but I don't see what is ensuring that the
> readers see g
m.au,
> mi...@kernel.org
> Sent: Thursday, February 26, 2015 1:28:17 PM
> Subject: Re: [RFC][PATCH] module: Optimize __module_address() using a latched
> RB-tree
>
> On Thu, Feb 26, 2015 at 05:43:56PM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 26, 2015 at 04:02:43PM +0
On Thu, Feb 26, 2015 at 05:43:56PM +0100, Peter Zijlstra wrote:
> On Thu, Feb 26, 2015 at 04:02:43PM +, Mathieu Desnoyers wrote:
> > Perhaps you could use mod_value() below, and introduce a
> > "mod_size()" too. This would keep the init vs core selection
> > out of the traversal code.
>
> Inde
On Thu, Feb 26, 2015 at 04:55:35PM +, Mathieu Desnoyers wrote:
> > +static unsigned long mod_value(struct module *mod, int idx)
> > +{
> > + if (idx & init_bit)
>
> Hrm, my first reflex is to look for a "init_bit" variable here.
> Should we use caps for enum entries instead ? e.g. INIT_BIT ?
On Thu, Feb 26, 2015 at 04:55:35PM +, Mathieu Desnoyers wrote:
> > Dunno, it seemed like a good a place as any.
>
> My personal coding-style is to put all definitions
> at the top of C files, but I don't know if it's within
> the kernel coding style guide lines or just something
> I'm personal
u, mi...@kernel.org
> Sent: Thursday, February 26, 2015 11:43:56 AM
> Subject: Re: [RFC][PATCH] module: Optimize __module_address() using a latched
> RB-tree
>
> On Thu, Feb 26, 2015 at 04:02:43PM +, Mathieu Desnoyers wrote:
> > Perhaps you could use mod_value() below, a
On Thu, Feb 26, 2015 at 04:02:43PM +, Mathieu Desnoyers wrote:
> Perhaps you could use mod_value() below, and introduce a
> "mod_size()" too. This would keep the init vs core selection
> out of the traversal code.
Indeed!
> Is it customary to define static variables in the
> middle of a C fil
,
> mi...@kernel.org
> Sent: Thursday, February 26, 2015 6:43:09 AM
> Subject: [RFC][PATCH] module: Optimize __module_address() using a latched
> RB-tree
>
> On Mon, Feb 23, 2015 at 09:43:40AM -0800, Andi Kleen wrote:
>
> > BTW if you really worry about perf overhead you
On Thu, Feb 26, 2015 at 12:43:09PM +0100, Peter Zijlstra wrote:
> +static struct module *__tree_find(struct rb_root *r, unsigned long addr)
> +{
> + struct rb_node *n = r->rb_node;
> +
> + while (n) {
> + struct module *m = mod_entry(n);
> + int idx = mod_node_idx(m
* Peter Zijlstra wrote:
> +static struct module *mod_tree_find(unsigned long addr)
> +{
> + struct module *m;
> + unsigned int seq;
> +
> + do {
> + seq = raw_read_seqcount(&mod_tree.seq);
> + m = __tree_find(&mod_tree.tree[seq & 1], addr);
> + } while (re
On Mon, Feb 23, 2015 at 09:43:40AM -0800, Andi Kleen wrote:
> BTW if you really worry about perf overhead you could
> gain far more (in some cases ms) by applying
> http://comments.gmane.org/gmane.linux.kernel/1805207
Yeah, how about something like so instead; it would work for everybody.
It
26 matches
Mail list logo
