This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Interesting reading regarding dtrace, aggregation and buffers...
- From: "Spirakis, Charles" <charles dot spirakis at intel dot com>
- To: "Martin Hunt" <hunt at redhat dot com>, "William Cohen" <wcohen at redhat dot com>
- Cc: <systemtap at sources dot redhat dot com>
- Date: Thu, 16 Jun 2005 13:22:36 -0700
- Subject: Interesting reading regarding dtrace, aggregation and buffers...
I'm guessing people have already seen this, but it was new to me:
Aggregation discussion:
http://docs.sun.com/app/docs/doc/817-6223/6mlkidlh7?a=view
The interesting aspect for me was:
Because DTrace buffers some aggregation data in the kernel,
space
might not be available when a new key is added to an
aggregation.
In this case, the data will be dropped, a counter will be
incremented, and dtrace will generate a message indicating an
aggregation drop.
--> This situation rarely occurs because
DTrace keeps long-running state (consisting of the aggregation's
key and intermediate result) at user-level where space may grow
dynamically.<--
In the unlikely event that aggregation drops occur, you can
increase
the aggregation buffer size with the aggsize option to reduce the
likelihood of drops...
Is this why they use the XXX = count() syntax (and other aggregation
specific functions)? So they can store part of the information in kernel
space, flush when appropriate to user space, then do the final
aggregation in user space? Note how they define aggregation at the top
(which gives them this ability: f(f(x1) U f(x2) U ...) == f(x1 U x2
U...) ).
As for the buffering methodology:
http://docs.sun.com/app/docs/doc/817-6223/6mlkidlho?a=view
By default, they are per-cpu, double buffered. They do provide a lot of
flexibility in how the buffers are managed.
-- charles