Sorry for jumping back into this discussion so much later...
Jonathan Adams wrote:
On Wed, Mar 08, 2006 at 11:32:05AM -0800, WILLIAM CHEN wrote:
In response to the question of what happens if the buffer never
overflows. One will not get an interrupt if the buffer does not
overflow. In this case, the event being monitored is very rare
or the application being monitored has a very short execution
time. In either case, the overhead of the interrupt is probably
not a problem, and the user can either choose not to user in-kernel
buffering for that event or simply ignore the events as being rare and
insignificant.
I'm asking purely from a correctness point of view; if I set up a buffer
with 10,000 entries, and 19,999 events occur, I don't see any way to get
the second half of my events out of the kernel. This seems like a hole
in the proposal.
Well, in one sense, the in-kernel buffering mechanism is a way to reduce the
granularity of overflow events. So if you've asked the kernel to buffer every
10,000 entries and you only get 19,999, then it doesn't seem unreasonable for
those last 9,999 entries to be thrown away if the process exits without taking
one more overflow to fill the in-kernel buffer.
But I'd say it's really up to the consumers of this API to say whether they'd
like to be able to collect samples before the in-kernel buffer has filled. The
API proposed here does seem to support such a scenario - call
cpc_set_sample_pcbuf() at any time to read its contents to userland and clear
the in-kernel buffer.
-----------------------------------------------------
Russ Blaine | Solaris Kernel | [EMAIL PROTECTED]
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
