Re: malloc probes for Systemtap

[Jeff Law <law at redhat dot com>]

On 10/03/2012 01:22 PM, Roland McGrath wrote:
> Of the primary maintainers, Carlos has done the malloc-related
> reviews lately.  So I'd like him to sign off on the choices of probe
> locations, names, and parameters.  Jeff's review seems to give some
> helpful rationale for some of the choices, though I didn't see him
> mention the parameters.
In general, the probe names are prefixed by the function they're 
contained within.  This seemed reasonable to me.  The alternate would be 
to prefix them all with "malloc" or something similar to denote the 
subsystem they're contained within.    I've got no strong opinions, so 
if you'd prefer subsystem prefixing, I'd go along with that happily.

As far as location, the locations are largely determined by what 
behaviours we want to probe for.  I thought they were pretty obvious. 
Perhaps I should have mentioned that the taps in some cases allow us to 
look at timestamps and determine how long we blocked on a mutex, this 
choice was made on purpose.

Parameters were pretty straightforward; in the mallopt probes I thought 
about asking for both the old and new values, but the old value will 
have been available the prior time the probe fired, so it seemed 
redundant.

Arguably malloc_arena_reuse_wait doesn't need to provide &result->mutex 
as that can be derived from the result argument.  Seemed like a nit to me.

The retry probes provide some basic info on the request that failed.  We 
get the failing arena via one of the probes which I'd expect to be 
useful as well as the size, alignment and other characteristics of the 
request that initially failed.

The resizing probes don't necessary have to pass h->size as they already 
pass h.  Seemed like a nit to me.  Providing the brk value & size seems 
pretty obviously useful.


> I'm certainly all for higher-quality documentation for probes, and I
> agree that those two .txt files are not stellar.  However, I really
> do not like the idea of dead conditional sections in the manual
> sources.  If you want to use Texinfo for this documentation (which
> of course is a perfectly fine choice) then I think it should be in
> separate files.
Then let's go with this, probes in their own chapter or appendix.  If we 
logically group them, that would tend to argue that the prefix would 
follow from the group rather than the function where the probe lives.

jeff