* Ted Ts'o ty...@mit.edu 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
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.
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, 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
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:
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;
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
* Peter Zijlstra a.p.zijls...@chello.nl 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
--
To
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
* Pekka Enberg penb...@cs.helsinki.fi 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
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,
* Peter Zijlstra a.p.zijls...@chello.nl 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
12 matches
Mail list logo
