Dear Graeme Russ,
In message 4DE383D3.7020008@gmail.com you wrote:
Some platforms are _way_ worse than this - I am sure I have seen a udelay() done with the millisecond time - So udelay(100) could be closer to udelay(1000) - So your above 5 second delay could take as long as 50 seconds!!!
That should show up quickly as soon as you run a "sleep 5" command on the console (which is implemented like that).
while (test_for_event() == 0) { now = get_timer(0); if ((now - start) > timeout) handle_timeout();
udelay(100);}
Here the loop overhead caused by short delay which may result in a high number of calls to test_for_event() gets eliminated because the time reference is independet of the delay.
I personally think _any_ timeout greater than 1s (maybe even >500ms) should be done this way
Agreed. As soon as the timeout is >> the interval size of the underlying timer service this is the best we can do.
start = get_timer(0);
do_something_complicated();
now = get_timer(0);
printf("execution time: %ld millisec\n", now - start);
Currently fails spectacularly if do_something_complicated() involves a delay loop which calls reset_timer()
Note that I (intentionally) always used argument 0 in the calls to get_timer(). I think we really should get rid of this argument.
I think this may become more popular for performance tuning once the API has been established. The desire for boot profiling was what initially made me investigate the API given the current use of reset_timer() prohibits profiling across a timeout loop.
Agreed.
Best regards,
Wolfgang Denk