lkml.org 
[lkml]   [1997]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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: '"

\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.050 / U:0.420 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site