To understand where bottlenecks are it is useful to have graphs of CPU, RAM and disk bandwidth utilization during the entire build. In addition, when using rm_work.bbclass, the currently consumed disk space is also interesting. These values need to be sampled at regular time intervals. Small intervals yield more detailed information, but also consume more disk space. Code is available: https://github.com/pohly/poky/commits/rmwork Open questions: should sampling be active by default when buildstats.bbclass is active? How often should be sampled? Is further work needed to reduce the disk space required to store the samples (which would be possible)?
RP suggested that sampling should be active by default. The bitbake heartbeat patch needs further work to make the interval configurable and should default to 1s (BB_HEARTBEAT_EVENT = "1.0"). Allowing time units was considered, with no clear consensus (it would be nicer, but there's no established standard for it). When recording by default, some additional work to lower the amount of stored data and thus the required parsing time would be useful.
Merged into bitbake and OE-core master ("buildstats: add system state sampling"), with condensed data stored in data files and enabled by default when inheriting buildstats.bbclass.