Interesting reading regarding dtrace, aggregation and buffers...

["Spirakis, Charles" <charles dot spirakis at intel dot com>]

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