On Tue, 2011-11-08 at 13:59 +0100, Ingo Molnar wrote:
>
> > Also the self monitor stuff, perf-tool doesn't use that for obvious
> > reasons.
>
> Indeed, and that's PAPI's strong point.
>
> We could try to utilize it via some clever LD_PRELOAD trickery?
Wouldn't be really meaningful, a perf-tes
* Peter Zijlstra wrote:
> On Tue, 2011-11-08 at 13:15 +0100, Ingo Molnar wrote:
> >
> > The one notable thing that isnt being tested in a natural way is
> > the 'group of events' abstraction - which, ironically, has been
> > added on the perfmon guys' insistence. No app beyond the PAPI
> > s
On Tue, 2011-11-08 at 13:15 +0100, Ingo Molnar wrote:
>
> The one notable thing that isnt being tested in a natural way is the
> 'group of events' abstraction - which, ironically, has been added on
> the perfmon guys' insistence. No app beyond the PAPI self-test makes
> actual use of it though,
* Pekka Enberg wrote:
> [...] There's an easy fix for this too: improve "perf test" to
> cover the cases you're intested in. While ABI spec would be a nice
> addition, it's not going to make compatibility problems magically
> go away.
Yes, exactly - 'perf test' has been written with that exa
On Tue, 8 Nov 2011, Frank Ch. Eigler wrote:
Almost: they demonstrate that those parts of the ABI that these
particular perf commands rely on have been impressively compatible.
Do you have any sort of ABI coverage measurement, to see what
parts of the ABI these perf commands do not use?
It's pre
* Peter Zijlstra wrote:
> The ABI yes, the tool no, the tool very much relies on some newer
> ABI parts. Supporting fallbacks isn't always possible/wanted.
Yeah, sure - and an older tool cannot possibly support newer features
either.
Thanks,
Ingo
Hi -
On Tue, Nov 08, 2011 at 11:22:35AM +0100, Ingo Molnar wrote:
> [...] These examples show *PICTURE PERFECT* forwards ABI
> compatibility, using the ancient perf tool on a bleeding edge
> kernel. [...]
Almost: they demonstrate that those parts of the ABI that these
particular perf commands r
On Tue, 8 Nov 2011, Theodore Tso wrote:
We have the staging tree because it's a widely acknowledged belief that
kernel code in the tree tends to improve over time compared to code
that's sitting out of the tree. Are you disputing that belief?
Kernel code in the kernel source tree improves; bec
On Nov 8, 2011, at 6:20 AM, Pekka Enberg wrote:
> We have the staging tree because it's a widely acknowledged belief that
> kernel code in the tree tends to improve over time compared to code that's
> sitting out of the tree. Are you disputing that belief?
Kernel code in the kernel source tree
On Tue, 8 Nov 2011, Theodore Tso wrote:
It's great to hear that! But in that case, there's an experiment we
can't really run, which is if perf had been developed in a separate
tree, would it have been just as successful?
Experiment, eh?
We have the staging tree because it's a widely acknowl
On Nov 8, 2011, at 5:22 AM, Ingo Molnar wrote:
> We do even more than that, the perf ABI is fully backwards *and*
> forwards compatible: you can run older perf on newer ABIs and newer
> perf on older ABIs.
It's great to hear that! But in that case, there's an experiment we can't
really run,
On Tue, 2011-11-08 at 11:22 +0100, Ingo Molnar wrote:
>
> We do even more than that, the perf ABI is fully backwards *and*
> forwards compatible: you can run older perf on newer ABIs and newer
> perf on older ABIs.
The ABI yes, the tool no, the tool very much relies on some newer ABI
parts. Su
* Ted Ts'o wrote:
> I don't believe there's ever been any guarantee that "perf test"
> from version N of the kernel will always work on a version N+M of
> the kernel. Perhaps I am wrong, though. If that is a guarantee
> that the perf developers are willing to stand behind, or have
> already
13 matches
Mail list logo
