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.