commit f3b111a3d16ff020092bb55d90a494b72eb7f7c7
author Zimuzo Ezeozue <zezeozue@google.com> Tue Aug 06 18:53:31 2024 +0100
committer Zimuzo Ezeozue <zezeozue@google.com> Thu Aug 08 12:20:04 2024 +0100
tree 8f4de27a412fd25fc90a691b2f41fe39c8d0ff52
parent 061338ca7eda28bf86f1f1a3b7f4f0d7ed1c5a7e

[sdlib]: Add logical binder breakdowns

Historically, we've reasoned about binder transaction latency in terms
of thread_states (and kernel blocking functions) or monitor contention.

This disjointed view hides the real picture, for instance from a
thread_state perspective, while a binder reply is Sleeping in the
'S' state, it could broadly be doing any of the:
following:
1. Sleeping due to some timer or interrupt.
2. Blocked on a lock (in Java or CPP).
4. Making another binder transaction.

From a monitor contention perspective, a binder txn could be actually
sleeping or contending for CPU. In the later case, waiting on CPU is the
more interesting 'reason'.

Now, we intersect the slice (flattened) and thread_state to deduce
a logical reason in every intersecting partition. This new reason doesn't
suffer from the examples above and we can more accurately identify stall
reasons during a binder txn on the client and server side.

Test: tools/diff_test_trace_processor.py out/android/trace_processor_shell --name-filter '.*binder.*'
Change-Id: I621a6cb7bf761e5148654a73e58dc5d0ae214e37