commit c1a4e87442626f1853a7269cee5734dedd9fbd0d
author Ryan Savitski <rsavitski@google.com> Wed Dec 16 19:56:48 2020 +0000
committer Ryan Savitski <rsavitski@google.com> Wed Dec 16 19:56:48 2020 +0000
tree 95d6a7712d728c4d875aedb9e5f94623ca082c47
parent 135a288024695f11142594049268f9217914d8fa

traced_perf: add memory guardrail (stops the DS if daemon above limit)

Normally, when a source is stopped, traced_perf:
* pauses the perf_events stream
* waits for reader to drain the outstanding samples
* waits for the unwinder to unwind them
* cleans up and acks the StopDataSource

Instead, this patch introduces an option for stopping the work abruptly,
immediately erasing the data source state from both the reader and
unwinder stages.

Note: the tracing service (traced) doesn't respect producer stop
notifications unless the service itself started the stop sequence. So we
can't just NotifyDataSourceStopped(), and will keep receiving flush &
stop request IPCs for the DS that we've forgotten about. I believe it's
safe to blindly ack unknown flushes and stops (as the service should be
accutrate about routing the IPCs in the first place). Do tell if I'm
overlooking an important detail though.

An alternative would've been to introduce a new DS status (kTombstoned
or similar), and propagate that knowledge until the StopDataSource IPC.
But I don't think that complexity is worth it.

Note: I went with a separate periodic task per guardrail'd DS. Having
concurrent sources should be rare, so it doesn't feel worth sharing the
mem footprint calculation cost. Also, this will allow us to introduce a
guardrail check period as part of the trace config, should we need that
flexibility.

Change-Id: I6d585e6728991141e1ab8bd0b8f6b2ad6fe6d5fc