commit c1855300622a13ef3c2173bfab9edaf845161ddd
author Primiano Tucci <primiano@google.com> Thu Dec 06 10:36:55 2018 +0000
committer Primiano Tucci <primiano@google.com> Thu Dec 06 10:36:55 2018 +0000
tree 1369671160511f68f27965c92b7abf92ae619e12
parent c30ed73dd52ad9aa63b079e1fa41abd88468a034

Implement ftrace flushing

This CL finally implements flushing of ftrace data and
wires it up to the Flush() API of the tracing service.
The major change introduced is in CpuReader, the multi
threaded class that reads ftrace data.
The core scheduling algorithm is left unchanged (see
//docs/ftrace.md). The old logic is still preserved:
[wait for command] -> [splice blocking] -> [splice nonblock]
However, this CL introduces a way for the FtraceController
to interrupt the splice and switch to read() mode for
flushes. read(), in fact, is the only way to read partial
pages out of the ftrace buffer.
Even when in read() mode, the scheduling algorithm is still
the same, just s/splice/read/.
There are a bunch of caveats and they are thoroughly
described in b/120188810. Essentially once we switch to
read() for the flush, we need to be careful and wait for
the ftrace read pointer to become page-aligned again before
switching back to splice().
Furthermore this CL gets rid of the internal pipe to move
data between the worker thread and the main thread and switches
to the recently introduced page pool. We still have an internal
pipe (for splice) but use it entirely in the worker therad.
Exposing the pipe to the main thread had two drawbacks:
1) Essentially limits the transfer bandwidth between the worker
   thread and the main thread, making the ftrace buffer size
   useless. Before, even if one specified a buffer size of 1GB,
   we would at most read 1 pipe buffer per read cycle.
2) That hits another kernel bug around non-blocking splice
   (b/119805587).

Test: perfetto_integrationtests --gtest_filter=PerfettoTest.VeryLargePackets
Bug: 73886018
Change-Id: I4a6e82b284971a3765b42959904f5402095e4c4e