On Mon, Jan 11, 2016 at 01:48:18PM +0000, Wang Nan wrote:
This patch introduces a PERF_SAMPLE_TAILSIZE flag which allows a sizeadding extra 8 bytes for every sample is quite unfortunate.
field attached at the end of a sample. The idea comes from [1] that,
with tie size at tail of an event, it is possible for user program who
read from the ring buffer parse events backward.
For example:
head
|
V
+--+---+-------+----------+------+---+
|E6|...| B 8| C 11| D 7|E..|
+--+---+-------+----------+------+---+
In this case, from the 'head' pointer provided by kernel, user program
can first see '6' by (*(head - sizeof(u64))), then it can get the start
pointer of record 'E', then it can read size and find start position
of record D, C, B in similar way.
How about another idea:
. update data_tail pointer when head is about to overwrite it
Ex:
head data_tail
| |
V V
+--+-------+-------+---+----+---+
|E | ... | B | C | D | E |
+--+-------+-------+---+----+---+
if new sample F is about to overwrite B, the kernel would need
to read the size of B from B's header and update data_tail to point C.
Or even further.
Comparing to TAILSIZE approach, now kernel will be doing both reads
and writes into ring-buffer and there is a concern that reads may
be hitting cold data, but if the records are small they may be
actually on the same cache line brought by the previous
read A's header, write E record cycle. So I think we shouldn't see
cache misses.
Another concern is validity of records stored. If user space messes
with ring-buffer, kernel won't be able to move data_tail properly
and would need to indicate that to userspace somehow.
But memory saving of 8 bytes per record could be sizable
andPlease also refer to [3]. In that patch we introduced a userspace
user space wouldn't need to walk the whole buffer backwards and
can just start from valid data_tail, so the dumps of overwrite
ring-buffer will be faster too.
Thoughts?