commit c46d4dc95cb585f60d6590af5eb44a4b69626f1a
author Ryan Savitski <rsavitski@google.com> Tue Feb 04 15:03:38 2020 +0000
committer Ryan Savitski <rsavitski@google.com> Tue Feb 04 15:03:38 2020 +0000
tree 3b0ebfaba9f99755d47b809b905e789041d7e178
parent 349930ee9cd34406a3f58c9bde403d9e330ae298

traced_perf: rework reading granularity, add unwind queue

The implementation is kept single-threaded, but the organization roughly
follows the intended unwinder-on-a-dedicated-thread approach.

There's a mix of smaller changes, summarizing in no particular order:
* Reading now consumes individual records instead of chunks of the ring buffer.
  (The records will be either a sample, or a PERF_RECORD_LOST if the kernel has
  lost samples due to ring buffer capacity). I didn't want to bubble up the
  record type decision all the way to the PerfProducer, proposing the
  callback+return format of ReadUntilSample to abstract most of it away (though
  noting that it ends up hiding a nested loop).
* Reading parses the event directly out of the ring buffer (copying the
  populated stack bytes onto the heap, etc).
* The wrapped ringbuffer case is handled by reconstructing (with a pair of
  memcpy's) the event in a dedicated buffer, and returning a pointer to that.
* Added boot clock timestamps to samples.
* Added proc-fd interface, and direct/signal-based implementations.
* Added per-datasource unwinder queues (for now simply std::deque while we're
  single-threaded, imagine a ring buffer in the future).

On unwinding queues specifically - the slots are filled in order (from the
perspective of a given per-cpu buffer reader). The parsing however can be out
of order, as samples are kept in the queue until their proc-fds are ready (or
assumed to not be obtainable for the remainder of the data source's lifetime).
The "unwind" tick keep walking the queue in order, only releasing the completed
entries once they reach the "oldest" end of the queue.

Bug: 144281346
Change-Id: Ic59c153c1c80e04b5e5bfb25656c10bc5e80dd11