Messages in this thread | | | Date | Mon, 15 Sep 1997 13:12:03 +0200 | From | Martin Mares <> | Subject | Re: loops_per_sec |
| |
Hi,
> I was playing with nanosleep() and SCHED_FIFO, precisely with 500ns > delays on a P100. As I suspected some problem I inspected the code. > > nanosleep() calls udelay() which in turn only has 1 microsecond > resolution. > > Therefore I tried to find udelay(). Was a bit tricky as it's in a > include file. Well I saw that udelay uses delay() in turn, and that > uses loops_per_sec. All old news you'd say, so far. > > Then I wondered who sets loops_per_sec, and I found out that a _lot_ > of code uses loops_per_sec directly to call delay(). As I think > udelay() is rather new in Linux, I'd suggest to modify the obsolete > code to use udelay() (unless a delay shorter than 1 microsecond is > used).
I don't understand why udelay() is inline -- IMHO it would be useful to make it a standard function using loops_per_sec on [34]86's and the cycle counter on 586+. Another possibility is to read current value of the hardware timer instead. This would eliminate all the udelay alignment problems discussed some time ago.
Have a nice fortnight -- Martin `MJ' Mares <mj@gts.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Quote of the day: '"
| |