Re: [PATCH] PATCH: add framework for ndelay (nanoseconds)

Re: [PATCH] PATCH: add framework for ndelay (nanoseconds)

[Geert Uytterhoeven]

On Sun, 2 Feb 2003, Linux Kernel Mailing List wrote:
> ChangeSet 1.953.4.9, 2003/02/02 02:44:15-02:00, alan@lxorguk.ukuu.org.uk
> 
> 	[PATCH] PATCH: add framework for ndelay (nanoseconds)
> 	
> +void __ndelay(unsigned long usecs)
                               ^^^^^
> +{
> +	__const_udelay(usecs * 0x00005);  /* 2**32 / 1000000000 (rounded up) */
                       ^^^^^
> +}

Wouldn't it make more sense to call the parameter `nsecs' (or `ns')?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [PATCH] PATCH: add framework for ndelay (nanoseconds)

[Ivan Kokshaysky]

On Wed, Feb 05, 2003 at 03:34:31PM +0100, Geert Uytterhoeven wrote:
> On Sun, 2 Feb 2003, Linux Kernel Mailing List wrote:
> > ChangeSet 1.953.4.9, 2003/02/02 02:44:15-02:00, alan@lxorguk.ukuu.org.uk
> > 
> > 	[PATCH] PATCH: add framework for ndelay (nanoseconds)
> > 	
> > +void __ndelay(unsigned long usecs)
>                                ^^^^^
> > +{
> > +	__const_udelay(usecs * 0x00005);  /* 2**32 / 1000000000 (rounded up) */
>                        ^^^^^
> > +}
> 
> Wouldn't it make more sense to call the parameter `nsecs' (or `ns')?

There are more serious problems with this implementation:
1) It's *very* imprecise. Even on an 1 GHz CPU and with HZ = 100 precision
   is ~86 nsec. With HZ = 1000 it's almost unusable on *any* CPU.
2) Additional delay caused by integer multiplication, cache misses
   and so on may be large enough, especially on older processors.
   On 233 MHz PII it's 600-700 nsec (perfectly repeatable), on 600 MHz
   alpha ev56 - 200-300 nsec.

As of current 2.4, there is the only user of ndelay() - ide_execute_command()
that calls ndelay(400). Why udelay(1) cannot be used instead?

Ivan.

Re: [PATCH] PATCH: add framework for ndelay (nanoseconds)

[Alan Cox]

On Thu, 2003-02-06 at 14:49, Ivan Kokshaysky wrote:
> > Wouldn't it make more sense to call the parameter `nsecs' (or `ns')?
> 
> There are more serious problems with this implementation:
> 1) It's *very* imprecise. Even on an 1 GHz CPU and with HZ = 100 precision
>    is ~86 nsec. With HZ = 1000 it's almost unusable on *any* CPU.

HZ = 1000 isn't a 2.4 thing.

> As of current 2.4, there is the only user of ndelay() - ide_execute_command()
> that calls ndelay(400). Why udelay(1) cannot be used instead?

Why waste 500nS every IDE command as opposed to doing the job right ? The initial
ndelay() is a quick implementation. If you don't like it implement a better one,
if your box isnt fast implement it as udelay.

In the 2.5 tree I also hope we can avoid the ndelay in some cases

Alan

Re: [PATCH] PATCH: add framework for ndelay (nanoseconds)

[Ivan Kokshaysky]

On Thu, Feb 06, 2003 at 03:53:05PM +0000, Alan Cox wrote:
> Why waste 500nS every IDE command as opposed to doing the job right ? The initial
> ndelay() is a quick implementation. If you don't like it implement a better one,
> if your box isnt fast implement it as udelay.

Ok, I see. Probably i386 and others need additional shifts to improve
precision.
BTW, on alpha it's non-issue, despite that initial overhead.

Ivan.

Re: [PATCH] PATCH: add framework for ndelay (nanoseconds)

[Ross Biro]

Alan Cox wrote:

>Why waste 500nS every IDE command as opposed to doing the job right ? The initial
>ndelay() is a quick implementation. If you don't like it implement a better one,
>if your box isnt fast implement it as udelay.
>  
>
The delay should be made controller specific.  On most controllers the 
reading of the alt status we need to do to flush the write command to 
the drive will also cause enough of a delay so that the ndelay isn't 
needed at all.  For example the on the Promise 20265 and 20267 the alt 
status read will always take at least 600ns.

    Ross