MMC Request Latency Tracing: Absent Kernel Tracepoint for SDHCI Completion Events

Goal

Isolate the SDHCI controller's per-request completion latency from ext4 journaling and page-cache overhead during random write workloads on Raspberry Pi 4.

Constraints and Uncertainty

The upstream kernel exposes no tracepoint for mmc_request_done or SDHCI interrupt latency, so ftrace cannot attribute latency spikes to the controller versus the card's internal wear-leveling. CPU frequency scaling (ondemand governor) does not incorporate MMC queue depth into its load metric, causing frequency drops during I/O wait that further distort measurements. Benchmarks such as fio with --direct=1 still traverse the block layer, conflating host-side scheduling with the card's opaque firmware behavior. Thermal throttling on Pi 4 adds a confounding variable unless vcgencmd is polled continuously.

Questions

1. Can a minimal out-of-tree trace module capture MMC request submission-to-completion latency without perturbing the SDHCI driver's interrupt path?
2. Does the SD card's internal wear-leveling produce latency distributions that remain indistinguishable from host-side scheduler jitter when only block-layer timestamps are available?