Messages in this thread | | | Date | Wed, 12 Dec 2007 12:03:30 +0100 | From | Ingo Molnar <> | Subject | Re: x86, ptrace: support for branch trace store(BTS) |
| |
* Metzger, Markus T <markus.t.metzger@intel.com> wrote:
> Andi suggested to make this a sysctl.
that's just as arbitrary ...
> Would it be safe to drop the artificial limit and let the limit be the > available memory?
no, that would be a DoS :-/
mlock() is rlimit controlled and is available to unprivileged users - up to a small amount of memory can be locked down. But i agree that mlock() can be problematic - see below.
> > There's also no real mechanism that i can see to create a guaranteed > > flow of this information between the debugger and debuggee (unless i > > missed something), the code appears to overflow the array, and > > destroy earlier entries, right? That's "by design" for debugging, > > but quite a limitation for instrumentation which might want to have > > a reliable stream of the data (and would like the originating task > > to block until the debugger had an opportunity to siphoon out the > > data). > > That's correct as well. My focus is on debugging. And that's actually > the most useful behavior in that case. I'm not sure what you mean with > 'instrumentation'.
the branch trace can be used to generate a very finegrained profile/histogram of code execution - even of rarely executed codepaths which cannot be captured via timer/perf-counter based profiling.
another potential use would be for call graph coverage testing. (which currently requires compiler-inserted calls - would be much nicer if we could do this via the hardware.)
etc. Branch tracing isnt just for debugging i think - as long as the framework is flexible enough.
> The actual physical memory consumption will be worse (or at best > equal) compared to kalloc()ed memory, since we need to pin down entire > pages, whereas kalloc() would allocate just the memory that is > actually needed.
i agree that mlock() has problems. A different model would be: no mlock and no get_user_pages() - something quite close to what you have already. Data is streamed out of the internal (hardware-filled, kmalloc()-ed, user-inaccessible) buffer, we stop task execution until it is copied to the larger, user-provided buffer. The debugging feature you are interested in could be enabled as a special-case of this mechanism: if the user-space buffer is not larger than the hardware buffer then no streaming is needed, you can just capture into the kernel buffer. User-space would have to do a PTRACE_BTS_DRAIN_BUFFER call (or something like that) to get the "final portion" of the branch trace out into the user-space buffer. [which, in your debugging special-case, would the full internal buffer.]
that way the kmalloc()-ed buffer becomes an internal detail of buffering that you rarely have to be aware of. (it could still be queried - like your patch does it now.)
or something else that is intelligent. Basically, what we'd like to have is a future-proof, extensible approach that does not necessarily stop at debugging and integrates this hardware capability into Linux intelligently.
Ingo
| |