On Sat, Jul 10, 2021 at 11:45:19AM +0800, Patrick Star wrote:
I saw flashrom process use too many cpu time when I use it to write flashchip. Then I strace the process, and found too many "clock_gettime(CLOCK_MONOTONIC...)" system call.
This is odd.
clock_gettime(CLOCK_MONOTONIC...) shouldn't normally show up in strace (since most architectures arrange implement it in the vdso there are no syscalls to trace when running this function).
And located it to udelay.c line 39, in function clock_usec_delay(). So I replace the code with just usleep(), as below, static void clock_usec_delay(int usecs) { usleep(usecs); } And it still worked well, and use much less cpu time, and the time spend on erase&write a chip is basicly the same as before.
Also I write image to a flashchip and read it out with the modified flashrom many times, and the read out results are always same as the original image.
So why not use usleep() to save cpu time ?
For the very short delays used by some programmers the cost of sleeping might simply outweigh the cost of a spinning wait.
More likely though this is there to prevent issues on some systems (notably those without hrtimers) when a short sleep results in the calling thread being asleep for *much* longer than requests. This causes very slow programmer performance in some cases. 100x or even 1000x slowdown is not implausible.
Of course the break even point will be different on different systems. flashrom's internal_delay() function is pretty conservative to allow it to run well even on systems without hrtimers. The impact will also very between different programmers since some programmers delay for much longer than others.
Daniel.