This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap 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] |
Hi - hunt wrote: > I assume the efficiency increases are due to using per-cpu data then > combining that at probe exit? Correct. > If the aggregation is a vector, we currently aren't going to see any > efficiency increase because the map will have to be locked. [...] Not quite - one plausible implementation is for the translator to create parallel per-cpu map objects, and not apply locking to them at all. > [...] It is cheap to track them all. Perhaps so, for the simple aggregates. > That's what the maps do now. Yes, but I don't consider it clear that the map routines should deal with statistics at all, as distinct from an opaque value type that they copy (like my old templating-based variable-arity map prototype did). After all, statistics could be simple scalar values. > So then anything that uses "<<<" is an aggregate that tracks count, > sum, min, and max. Histograms are more complex and will need to be > declared. > [...] > var: count=1234 sum=134059 avg=108.6 min=5 max=311 > 0 ** > 10 ********** > [...] In the interest of compactness, it would be nice not to print much data that is not known to be of interest to the user. This could be another argument for not automagically computing all simple aggregates. - FChE
Attachment:
pgp00000.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |