[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150319144732.e57f1e22f636e41d3721873c@linux-foundation.org>
Date: Thu, 19 Mar 2015 14:47:32 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Peter Zijlstra <peterz@...radead.org>, mingo@...nel.org,
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, tglx@...utronix.de,
Michel Lespinasse <walken@...gle.com>,
Andrea Arcangeli <aarcange@...hat.com>,
David Woodhouse <David.Woodhouse@...el.com>,
Rik van Riel <riel@...hat.com>
Subject: Re: [PATCH 6/8] rbtree: Implement generic latch_tree
On Thu, 19 Mar 2015 17:36:36 -0400 Steven Rostedt <rostedt@...dmis.org> wrote:
> On Thu, 19 Mar 2015 13:58:33 -0700
> Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> > OK. This code is basically required to support perf/ftrace and
> > modules, yes? Presumably small and space-constrained systems aren't
> > using either, so they don't take the hit.
> >
> > However CONFIG_MODULES systems which aren't using perf/ftrace _do_ take
> > a hit. How many systems are we talking here? All non-x86?
>
> Compromise... (Totally untested)
>
> ...
>
> +config RBTREE_LATCH_INLINE
> + def_bool y
> + depends on PERF_EVENTS || TRACING
Should this be PERF_EVENTS, or PERF_EVENTS_NMI?
Could we just keep the old __module_address() for these configs? It's
only 10 lines..
--
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