diff options
| author | Frédéric Desbiens <[email protected]> | 2026-08-17 17:26:08 -0400 |
|---|---|---|
| committer | GitHub <[email protected]> | 2026-08-17 17:26:08 -0400 |
| commit | f535a4ec67456b9ba0cd8ecda3dfbf08894c17b3 (patch) | |
| tree | 5bfbdbe9e9a93eec3b23c7b32dccbf651ef08754 /common_modules/module_lib/src/txm_timer_delete.c | |
| parent | 367d91880b928a250c46c5b28486b8d932bf1e50 (diff) | |
Measured stack-heavy work against the memory holding the stack (#636)
#635 found BTCM worth about 7.4% on a context switch with no determinism
advantage, and said why: a switch saves sixteen registers, roughly one cache
line, so the stack's cache state has almost nothing to contribute. It named the
interesting case as work with a large stack working set, said it had not been
measured, and said it should not be assumed. This measures it, and the answer
inverts the earlier one.
deep_touch recurses 24 frames, writing a frame on the way down and reading it on
the way up, so the working set is the whole descent. The cache is cleaned and
invalidated before each sample, so every descent starts cold. Two threads, one
stack in BTCM and one in DRAM0, no partner threads and no relinquish: the timed
region is entirely within one thread.
Reproducible across runs:
min mean max spread
stack in BTCM 42868 43031 44890 2020
stack in DRAM0 42982 43291 49842 6860
The mean is the same to within 0.6%. The worst case is 10% lower for BTCM and
the spread is 3.4 times tighter. No sample in either configuration exceeded
twice the minimum, so these maxima are the workload rather than a timer tick --
which is the mistake that produced a false jitter result in #635 and is why the
count of interrupted samples is printed.
Put beside #635 the two measurements say opposite things and both are true.
For a context switch, a small footprint touched every time, BTCM buys throughput
and no determinism. For stack-heavy work, a large footprint touched once, it
buys determinism and almost no throughput.
The reason is that this workload is compute bound at the optimisation level this
BSP builds at: 43000 cycles for 24 frames is dominated by call and loop overhead,
so line fills are a few percent of the total and barely move the mean. What they
do is vary, and that variance is what a bank with no cache in the path removes.
So the determinism argument for TCM holds here, but it is worth 10% of worst case
and a threefold narrowing of spread, not an order of magnitude. Anyone citing
this in a safety argument should cite those numbers and not a larger claim.
Assisted-by: Claude Code (Opus 5) <[email protected]>
Diffstat (limited to 'common_modules/module_lib/src/txm_timer_delete.c')
0 files changed, 0 insertions, 0 deletions
