Re: [PATCH 3/3] delay: add generic udelay(), mdelay() and ssleep()

On Friday 22 September 2006 11:36, Russell King wrote:
On Fri, Sep 22, 2006 at 10:00:33AM +0200, Denis Vlasenko wrote:
* __const_udelay for all arches is removed or renamed to
? __const_delay (it did not do microsecond delays anyway)

You never explained this properly - in fact I think your logic is
reversed.

linux-2.6.18/arch/i386/lib/delay.c:

void __udelay(unsigned long usecs)
{
__const_udelay(usecs * 0x000010c7); /* 2**32 / 1000000 (rounded up) */
}

__udelay(n) is meant to busy loop for N microseconds,
and it is easy to see from above code that
__udelay(n) == __const_udelay(n*0x10c7).
So __const_udelay(x) doesn not delay for x microseconds.
It's a bad name.


Let me remind you of my reply (which afaics never got
a response):

On Wed, Aug 23, 2006 a 09:14:52AM +0100, Russell King wrote:
On Wed, Aug 23, 2006 at 07:50:24AM +0200, Denis Vlasenko wrote:
On Tuesday 22 August 2006 18:55, Russell King wrote:
Please keep a "const" version in ARM. Thanks.

Are you talking about this hunk? Why do you want to keep it?

I mean, without it udelay(n) will become slower by the time
needed for one extra multiply. So we will have maybe
udelay(n) ==> udelay(n+0.1).

Why do you think that? With the constant version, the additional
unnecessary multiply is optimised away by the compiler (since
constant * constant = constant), so it's actually slightly faster,
not sligntly slower as you seem to think.

Since the multiply is pure overhead, it's better to get rid of it.


I did send a reply. Maybe the problem was that I removed
l-k from CC...

On Wednesday 23 August 2006 10:39, Denis Vlasenko wrote:
Why do you think that? With the constant version, the additional
unnecessary multiply is optimised away by the compiler (since
constant * constant = constant), so it's actually slightly faster,
not sligntly slower as you seem to think.

We are not disagreeind. I said it wrong way. I meant
"with this #define removed, udelay(n) will become slower...".

And I am saying that it is _100% okay_ for it to become slower:

Since the multiply is pure overhead, it's better to get rid of it.

You do not need to optimize delay for speed. If you
really want to, then you can do:

#define udelay(n) do {} while(0)

Makes sense? No it does not. That's what I'm trying to say.
You WANT to pause for thousands of cycles. Why you are trying
to shave off ~10 cycles at the very same time?

Hope it makes things clearer.

So, to reiterate, optimizing udelay(N) for speed makes no sense.
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Kernel mode programming in VC++
    ... invalid premise that you can reprogram the timer chip. ... You'd have a delay measured in hundreds of milliseconds! ... but since it takes an unpredictable number of microseconds to get ... jmp short $+2 ...
    (microsoft.public.vc.mfc)
  • Re: Timer with Micro seconds
    ... thig is when i am trying to get microseconds delay with this code, ... letting other threads wiht lower priorities to run and using your ... consume more power (because your CPU can't get in idle mode etc.). ... thread priority if you need an exact delay and using SleepTillTick to ...
    (microsoft.public.windowsce.platbuilder)
  • Re: clock microseconds with resolution in milliseconds
    ... I have stumbled upon a strange behavior of the 'clock microseconds' ... I was trying to do a delay in microseconds (more precise then ... the after command). ...
    (comp.lang.tcl)
  • Re: Delay in milliseconds and need info abt Multimedia timers
    ... I was looking out for delay in microseconds. ... If you need a delay of a few microseconds, a non-blocking busy wait ... using QueryPerformanceCounter is the way to go, ...
    (microsoft.public.vc.stl)