[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150414123102.GK5029@twins.programming.kicks-ass.net>
Date: Tue, 14 Apr 2015 14:31:02 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: rusty@...tcorp.com.au, mathieu.desnoyers@...icios.com,
oleg@...hat.com, paulmck@...ux.vnet.ibm.com,
torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
andi@...stfloor.org, rostedt@...dmis.org, tglx@...utronix.de,
laijs@...fujitsu.com, linux@...izon.com
Subject: Re: [PATCH v5 07/10] module: Optimize __module_address() using a
latched RB-tree
On Mon, Apr 13, 2015 at 06:49:49PM +0200, Ingo Molnar wrote:
> * Peter Zijlstra <peterz@...radead.org> wrote:
> > +static __always_inline int
> > +mod_tree_comp(void *key, struct latch_tree_node *n)
> > +{
> > + unsigned long val = (unsigned long)key;
> > + unsigned long start, end;
> > +
> > + end = start = __mod_tree_val(n);
> > + end += __mod_tree_size(n);
> > +
> > + if (val < start)
> > + return -1;
> > +
> > + if (val >= end)
> > + return 1;
> > +
> > + return 0;
>
> So since we are counting nanoseconds, I suspect this could be written
> more optimally as:
>
> {
> unsigned long val = (unsigned long)key;
> unsigned long start, end;
>
> start = __mod_tree_val(n);
> if (val < start)
> return -1;
>
> end = start + __mod_tree_size(n);
> if (val >= end)
> return 1;
>
> return 0;
> }
>
> right?
I was afraid it would rip apart the common bits of
__mod_tree_{val,size}(), iow. it would end up doing the whole
latch_tree_node -> mod_tree_node -> mod and mtn_init comparison dance
twice.
But GCC does the right thing, so yes.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists