because udelay work on the principle that it know "how much work the
cpu can do in a time" and it work by just doing a loop of nothing, how
stable is it when the cpu clock rate is keep changing all the time?
does it update its loops_per_jiffy varible each time the cpu clock is change?
or does it have another solution to this problem?
or since before the cpu enter to this udelay function it must do some
work like entering the systemcall and so on , the cpu clock rate is
jump to the original?
"Yitzchak Eidus" <[email protected]> writes:
> because udelay work on the principle that it know "how much work the
> cpu can do in a time" and it work by just doing a loop of nothing, how
> stable is it when the cpu clock rate is keep changing all the time?
> does it update its loops_per_jiffy varible each time the cpu clock is change?
> or does it have another solution to this problem?
> or since before the cpu enter to this udelay function it must do some
> work like entering the systemcall and so on , the cpu clock rate is
> jump to the original?
Only on very old systems (pre ACPI APM era) does cpu frequency change without
the kernel knowing (ignoring Intel thermal throttling which is a different thing)
When the kernel knows it fixes loops_per_jiffy and normally does the necessary
synchronization over CPUs.
Obviously at least on multi core systems there are races with this.
Modern Intel CPUs (Yonah, Prescott) completely avoid the problem
because they have a constantly ticking TSC that is independent from
the actual clock rate. And __delay uses the TSC to measure time.
-Andi