[ Cc:-ed Alan Stern a'ka kwatch fame - Alan might be interested in this
too. ]
hi Markus,
finally had time to take a closer look at the design of your
Branch-Trace-Support-via-ptrace-on-x86 patchset. I think we'll need to
work some more on general API issues.
here's the current proposed API:
+ case PTRACE_BTS_MAX_BUFFER_SIZE:
+ case PTRACE_BTS_ALLOCATE_BUFFER:
+ case PTRACE_BTS_GET_BUFFER_SIZE:
+ case PTRACE_BTS_READ_RECORD:
+ case PTRACE_BTS_CONFIG:
+ case PTRACE_BTS_STATUS:
i can see a couple of open questions:
1) PTRACE_BTS_MAX_BUFFER_SIZE
why is a trace buffer size limit visible to user-space? It's 4000
entries right now:
#define PTRACE_BTS_BUFFER_MAX 4000
it would be more flexible if user-space could offer arbitrary sized
buffers, which the kernel would attempt to mlock(). Then those pages
could be fed to the BTS MSR. I.e. there should be no hard limit in the
API, other than a natural resource limit.
2) struct bts_struct
the structure of it is hardwired:
the basic unit is an array of bts_struct:
+struct bts_struct {
+ enum bts_qualifier qualifier;
+ union {
+ /* BTS_BRANCH */
+ struct {
+ long from_ip;
+ long to_ip;
+ } lbr;
+ /* BTS_TASK_ARRIVES or
+ BTS_TASK_DEPARTS */
+ unsigned long long timestamp;
+ } variant;
+};
while other CPUs (on other architectures, etc.) might have a different
raw format for the trace entries. So it would be better to implement BTS
support in kernel/ptrace.c with a general trace format, and to provide a
cross-arch API (only implemented by arch/x86 in the beginning) to
translate the 'raw' trace entries into the general format.
3)
it would certainly be useful for some applications to have a large
"virtual" trace buffer and a small "real" trace buffer. The kernel would
use BTS high-watermark interrupts to feed the real trace buffer into the
larger "virtual" trace buffer. This way we wouldnt even have to use
mlock() to pin down the trace buffer.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
