[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130812091707.GB27162@twins.programming.kicks-ass.net>
Date: Mon, 12 Aug 2013 11:17:07 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: LKML <linux-kernel@...r.kernel.org>, gcc <gcc@....gnu.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...nel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
"H. Peter Anvin" <hpa@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>,
David Daney <ddaney.cavm@...il.com>,
Behan Webster <behanw@...verseincode.com>
Subject: Re: [RFC] gcc feature request: Moving blocks into sections
On Mon, Aug 05, 2013 at 12:55:15PM -0400, Steven Rostedt wrote:
> [ sent to both Linux kernel mailing list and to gcc list ]
>
Let me hijack this thread for something related...
I've been wanting to 'abuse' static_key/asm-goto to sort-of JIT
if-forest functions like perf_prepare_sample() and perf_output_sample().
They are of the form:
void func(obj, args..)
{
unsigned long f = ...;
if (f & F1)
do_f1();
if (f & F2)
do_f2();
...
if (f & FN)
do_fn();
}
Where f is constant for the entire lifetime of the particular object.
So I was thinking of having these functions use static_key/asm-goto;
then write the proper static key values unsafe so as to avoid all
trickery (as these functions would never actually be used) and copy the
end result into object private memory. The object will then use indirect
calls into these functions.
The advantage of using something like this is that it would work for all
architectures that now support the asm-goto feature. For arch/gcc
combinations that do not we'd simply revert to the current state of
affairs.
I suppose the question is, do people strenuously object to creativity
like that and or is there something GCC can do to make this
easier/better still?
--
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