On 1/13/2025 12:09 PM, John Ogness wrote:
[...]
Yeah, I see the same behaviour with this way of running the test: The
core with the stressor on it shows small latencies and the other huge
ones. The effect disappears once I run two or more stressors, e.g.
taskset 0x4 stress -m 1 --vm-stride 16 --vm-bytes 512000000 --vm-keep -c 1
and
taskset 0x8 stress -m 1 --vm-stride 16 --vm-bytes 512000000 --vm-keep -c 1
Then all cores show huge latencies.
To me this looks like memory bus contention. I would expect you could
reproduce the same behavior with bare metal software.
Someone with some experience with this platform would need to speak
up. The usefulness of my casual responses has come to an end. ;-)
Your input is nonetheless very much appreciated :) Also the peculiar
dependence on the stride parameter which has an effect on what memory
banks are touched in what order and with what timing points in this
direction IMHO.
Another datapoint: When I set the cpu speed to 1.5 Ghz instead of 2.4 by
way of cpufreq-set -g powersave the effect is greatly diminshed which
also points into the contention direction.
Kind regards,
FPS
--
https://blog.dfdx.eu
