2002-09-21 11:18:06

by Jos Hulzink

[permalink] [raw]
Subject: udelay and nanosleep questions

Hi,

Talking about kernel driver programming:

1) Can I rely on udelay(1) ? i.e. is the resolution high enough to wait at
least 1 microsecond given it returns normally ? I know the actual
implementation is platform / cpu dependant, so maybe I should ask: Should
I be able to rely on udelay(1) ?

2) With the highspeed CPUs these days, the implementation of sys_nanosleep
(in kernel/timer.c) for realtime processes:

sys_nanosleep {udelay ((nsec+999)/1000}

is rather low-res. Time for something new ? sys_nanosleep seems not the
call to make for in-kernel accurate delays, for it schedules a timeout
instead of doing a busy wait. My driver needs 250 ns delays, is there a
more accurate way than udelay(1) ? It is a pity to waste 4x more
clockcycli than needed.

3) Usleep and friends seem not to care about speedstepping technologies.
Shouldn't we care, at least for in-kernel and realtime process waits ?
True, you are an idiot when running realtime processes on a speedstep
enabled CPU, but still...

Jos


2002-09-21 11:30:42

by Russell King

[permalink] [raw]
Subject: Re: udelay and nanosleep questions

On Sat, Sep 21, 2002 at 01:23:10PM +0200, Jos Hulzink wrote:
> 1) Can I rely on udelay(1) ? i.e. is the resolution high enough to wait at
> least 1 microsecond given it returns normally ? I know the actual
> implementation is platform / cpu dependant, so maybe I should ask: Should
> I be able to rely on udelay(1) ?

udelay() should (note: should) busy wait for at least the requested delay.
It may wait longer though.

Its behaviour in the presence of speedstep type technologies where cpufreq
is not in use is a little undefined; almost anything can happen. However,
with cpufreq in place, we adjust the delay value appropriately so that
a udelay() always sleeps for at least the requested time.

--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

2002-09-22 03:46:47

by George Anzinger

[permalink] [raw]
Subject: Re: udelay and nanosleep questions

Jos Hulzink wrote:
>
> Hi,
>
> Talking about kernel driver programming:
>
> 1) Can I rely on udelay(1) ? i.e. is the resolution high enough to wait at
> least 1 microsecond given it returns normally ? I know the actual
> implementation is platform / cpu dependant, so maybe I should ask: Should
> I be able to rely on udelay(1) ?
>
> 2) With the highspeed CPUs these days, the implementation of sys_nanosleep
> (in kernel/timer.c) for realtime processes:
>
> sys_nanosleep {udelay ((nsec+999)/1000}
>
> is rather low-res. Time for something new ? sys_nanosleep seems not the
> call to make for in-kernel accurate delays, for it schedules a timeout
> instead of doing a busy wait. My driver needs 250 ns delays, is there a
> more accurate way than udelay(1) ? It is a pity to waste 4x more
> clockcycli than needed.
>
> 3) Usleep and friends seem not to care about speedstepping technologies.
> Shouldn't we care, at least for in-kernel and realtime process waits ?
> True, you are an idiot when running realtime processes on a speedstep
> enabled CPU, but still...

You might want to check out the high-res-timers stuff. We
will be sending this in soon for 2.5, for 2.4, see the link
below.

-g
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

--
George Anzinger [email protected]
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml