This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: malloc probes for Systemtap


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]