On Sat, 07 Sep 2019 09:14:49 -0700, Theodore Dubois said: Reading what it actually says rather than what I thought it said.. :) Events come in two flavors: counting and sampled. A counting event is one that is used for counting the aggregate number of events that occur. In general, counting event results are gathered with a read(2) call. A sampling event periodically writes measurements to a buffer that can then be accessed via mmap(2). For some reason, I was thinking counting events. -ENOCAFFEINE. :)
sample_freq is 4000 (and freq is 1). Here’s the man page on this field:
sample_period, sample_freq A "sampling" event is one that generates an overflow notifica‐ tion every N events, where N is given by sample_period. A sam‐ pling event has sample_period > 0.
There's this part:
pling event has sample_period > 0. When an overflow occurs, requested data is recorded in the mmap buffer. The sample_type field controls what data is recorded on each overflow.
So an entry is made in the buffer. It's not clear that this immediately triggers a signal... MMAP layout When using perf_event_open() in sampled mode, asynchronous events (like counter overflow or PROT_EXEC mmap tracking) are logged into a ring- buffer. This ring-buffer is created and accessed through mmap(2). The mmap size should be 1+2^n pages, where the first page is a metadata page (struct perf_event_mmap_page) that contains various bits of infor? mation such as where the ring-buffer head is. So you need to look at what size mmap buffer is being allocated. It's *probably* on the order of megabytes, so that you can buffer a fairly large number of entries and not take several user/kernel transitions on every single entry...
If I’m reading this right, this is a sampling event which overflows 4000 times a second.
And 4,000 entries are made in the buffer per second..
But perf then does a poll call which wakes up on this FD with POLLIN after 1.637 seconds, instead of 0.00025 seconds
At which point perf goes and looks at several thousand entries in the ring buffer...