Date:	Wed, 12 Dec 2007 12:03:30 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	"Metzger, Markus T" <markus.t.metzger@...el.com>
Cc:	ak@...e.de, hpa@...or.com, linux-kernel@...r.kernel.org,
	tglx@...utronix.de, markus.t.metzger@...il.com,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>, roland@...hat.com,
	akpm@...ux-foundation.org, mtk.manpages@...il.com,
	Alan Stern <stern@...land.harvard.edu>
Subject: Re: x86, ptrace: support for branch trace store(BTS)


* Metzger, Markus T <markus.t.metzger@...el.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists