On 01/27/2010 01:05 PM, Ananth N Mavinakayanahalli wrote:
We don't need to write one. I don't know how easy it is to make the kvm
emulator less kvm-centric (vcpus, kvm_context, etc). Avi?
It's a lot of mindless work but not too difficult; replacing hardcoded
accessors with function
On 01/27/2010 12:23 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
(back from vacation)
If so then you ignore the obvious solution to _that_ problem: dont use
INT3 at all, but rebuild (or re-JIT) your program with explicit callbacks.
It's _MUCH_ faster than _any_ breakpoint
On 01/27/2010 10:24 AM, Ingo Molnar wrote:
Not to mention that that process could wreck the trace data rendering it
utterly unreliable.
It could, but it also might not. Are we going to deny high performance
tracing to users just because it doesn't work in all cases?
Tracing
On 01/19/2010 07:47 PM, Jim Keniston wrote:
This is still with a kernel entry, yes?
Yes, this involves setting a breakpoint and trapping into the kernel
when it's hit. The 6-7x figure is with the current 2-trap approach
(breakpoint, single-step). Boosting could presumably make that
On 01/20/2010 11:57 AM, Peter Zijlstra wrote:
On Wed, 2010-01-20 at 11:43 +0200, Avi Kivity wrote:
1. Write a trace entry into shared memory, trap into the kernel on overflow.
2. Trap if a condition is satisfied (fast watchpoint implementation).
So now you want to consume more
On 01/20/2010 12:45 PM, Srikar Dronamraju wrote:
What does the code in the jumped-to vma do?
1. Write a trace entry into shared memory, trap into the kernel on overflow.
2. Trap if a condition is satisfied (fast watchpoint implementation).
That looks to be a nice idea. We should
On 01/19/2010 12:15 AM, Jim Keniston wrote:
I don't like the idea but if the performance benefits are real (are
they?),
Based on what seems to be the closest thing to an apples-to-apples
comparison -- counting the number of calls to a specified function --
uprobes is 6-7 times faster
On 01/18/2010 09:45 AM, Peter Zijlstra wrote:
This is debugging. We're playing with registers, we're playing with the
cpu, we're playing with memory contents. Why not the address space as well?
Because you want thins go to be as transparent as possible in order to
avoid heisenbugs.
On 01/18/2010 01:44 PM, Peter Zijlstra wrote:
On Mon, 2010-01-18 at 13:01 +0200, Avi Kivity wrote:
You've made it clear that you don't like it, but not why.
The kernel already manages the user's address space (except for
MAP_FIXED which is unreliable unless you've already reserved
On 01/18/2010 02:06 PM, Peter Zijlstra wrote:
On Mon, 2010-01-18 at 14:01 +0200, Avi Kivity wrote:
Maybe you place no value on uprobes. But people who debug userspace
likely will see a reason.
I do see value in uprobes, I just don't like it mucking about with the
address space. Nor
On 01/18/2010 02:13 PM, Pekka Enberg wrote:
So how big chunks of the address space are we talking here for uprobes?
That's for the authors to answer, but at a guess, 32 bytes per probe
(largest x86 instruction is 15 bytes), so 32 MB will give you a million
probes. That's a piece of cake
On 01/18/2010 02:51 PM, Pekka Enberg wrote:
And how many probes do we expected to be live at the same time in
real-world scenarios? I guess Avi's one million is more than enough?
I don't think a user will ever come close to a million, but we can
expect some inflation from inlined
On 01/18/2010 02:57 PM, Pekka Enberg wrote:
On 01/18/2010 02:51 PM, Pekka Enberg wrote:
And how many probes do we expected to be live at the same time in
real-world scenarios? I guess Avi's one million is more than enough?
Avi Kivity kirjoitti:
I don't think a user will ever come close
On 01/18/2010 03:15 PM, Peter Zijlstra wrote:
On Mon, 2010-01-18 at 14:37 +0200, Avi Kivity wrote:
On 01/18/2010 02:14 PM, Peter Zijlstra wrote:
Well, the alternatives are very unappealing. Emulation and
single-stepping are going to be very slow compared to a couple of jumps
On 01/18/2010 05:43 PM, Ananth N Mavinakayanahalli wrote:
Well, the alternatives are very unappealing. Emulation and single-stepping
are going to be very slow compared to a couple of jumps.
So how big chunks of the address space are we talking here for uprobes?
As Srikar
On 01/16/2010 02:58 AM, Jim Keniston wrote:
I hear (er, read) you. Emulation may turn out to be the answer for some
architectures. But here are some things to keep in mind about the
various approaches:
1. Single-stepping inline is easiest: you need to know very little about
the instruction
On 01/17/2010 05:03 PM, Peter Zijlstra wrote:
btw, an alternative is to require the caller to provide the address
space for this. If the caller is in another process, we need to allow
it to play with the target's address space (i.e. mmap_process()). I
don't think uprobes justifies this by
On 12/19/2009 01:15 AM, Frederic Weisbecker wrote:
Apparently it does. You should hack some printks into do_debug() and see
how kvm is differing from real hardware. (Actually you can probably do
this with a notifier added by a module, not that you are shy about
recompiling!)
Probably kvm's
18 matches
Mail list logo
