[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <y0m39tkdocs.fsf@fche.csb>
Date: Wed, 08 Sep 2010 15:30:59 -0400
From: fche@...hat.com (Frank Ch. Eigler)
To: Ingo Molnar <mingo@...e.hu>
Cc: Pekka Enberg <penberg@...nel.org>,
Paul Mackerras <paulus@...ba.org>, Avi Kivity <avi@...hat.com>,
Pekka Enberg <penberg@...helsinki.fi>,
Tom Zanussi <tzanussi@...il.com>,
=?iso-8859-1?Q?Fr=E9d=E9ric?=
Weisbecker <fweisbec@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
linux-perf-users@...r.kernel.org,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: disabling group leader perf_event
mingo wrote:
> [...] Do you know some interesting usecase that would be excluded
> via such address restrictions?
You could study tracing-oriented runtime systems such as those of
dtrace, dprobes, or even systemtap, to help answer such questions.
> Things like flexible arrays or more complex data structures such as
> trees couldnt be used initially. More complex data structures would
> need locking in any case. [...] I.e. it would initially be
> restricted roughly to code where halting can be proven. Still looks
> interesting to me [...]
There are years of experience out there to learn from. Note the sorts
of filtering expressions (never mind control logic) used in the prior
art, so that you can know what you're about to sacrifice by a
simple-sounding implementation.
- FChE
--
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