The very same is true of profiling in the host space as well (KVM is nothing
special here, other than its unreasonable insistence on not enumerating
readily available information in a more usable way).
So are you suggesting a solution to a perf problem we already solved
differently? (and which i argue we solved in a better way)
We have solved that in the host space already (and quite elaborately so), and
not via your suggestion of moving symbol resolution to a different stage, but
by properly generating the right events to allow the post-processing stage to
see processes that have already exited, to robustly handle files that have
been rebuilt, etc.
From an instrumentation POV it is fundamentally better to acquire the right
data and delay any complexities to the analysis stage (the perf model) than to
complicate sampling (the oprofile dcookies model).
Your proposal of 'doing the symbol resolution in the guest context' is in
essence re-arguing that very similar point that oprofile lost. Did you really
intend to re-argue that point as well? If yes then please propose an
alternative implementation for everything that perf does wrt. symbol lookups.
What we propose for 'perf kvm' right now is simply a straight-forward
extension of the existing (and well working) symbol handling code to
virtualization.
Best would be if you demonstrated any problems of the perf symbol lookup code
you are aware of on the host side, as it has that exact design you are
criticising here. We are eager to fix any bugs in it.
If you claim that it's buggy then that should very much be demonstratable - no
need to go into theoretical arguments about it.
( You should be aware of the fact that perf currently works with 'processes
exiting prematurely' and similar scenarios just fine, so if you want to
demonstrate that it's broken you will probably need a different example. )
That is kind of half of my suggestion - the built-in enumeration guests and a
guaranteed channel to them accessible to tools. (KVM already has its own
special channel so it's not like channels of communication are useless.)
The other half of my suggestion is that if we bring this thought to its
logical conclusion then we might as well walk the whole mile and not use
quirky, binary API single-channel pipes. I.e. we could use this convenient,
human-readable, structured, hierarchical abstraction to expose information in
a finegrained, scalable way, which has a world-class implementation in Linux:
the 'VFS namespace'.
Thanks,
Ingo
--
