Calculating residencies more flexibly on a trace
Created by: joelagnel
Definition of residency (my definition): The total amount of run time or percentage of time a given PID runs on an entity (entities can be core, cluster, cgroup). In such calculations the idle time isn't accounted. It would be nice to add an API to calculate residencies per-PID, per-TGID and per-CGroup globally. For Android especially this is helpful to do because it gives better understanding per-usecase of which CPUs time is spent on. For example -
- For camera startup use case, we want Camera app's UiThread to be placed more on big cluster
- Processes in top-app and foreground CGroup should generally run more often on the big cluster
- For a background workload like System server's background thread, we want it to run most of the time on little cluster
It would helpful to auto analyze everything in the trace and present to the user statistics than manually select threads and do an analysis. Such analysis would be useful to be grouped per-TGID since several PID share the same name and its confusing for analysis when looking at individually PIDs. Its more useful to start from the TGID-level (like YouTube app) and then drill down from there.
Discussed with @derkling @sinkap and the callbacks API can be used here to speed things up, lets develop something along these lines. Either we can improve BART with callbacks API and call that from LISA or push new API to LISA based on the callbacks. I like the BART approach because the logic for "grouping" residency based on cluster level is already done there.
If going through LISA-only approach, I was thinking we add a new
ResidencyAnalysis class to
libs/utils/analysis to LISA which is flexible to cover different cases.
Lets chat what's the best design approach here to move forward, thanks.