From: "Denis Vlasenko" <vda.linux@googlemail.com>
To: "Arjan van de Ven" <arjan@infradead.org>
Cc: "Roman Zippel" <zippel@linux-m68k.org>,
"Jonathan Corbet" <corbet@lwn.net>,
linux-kernel@vger.kernel.org,
"Thomas Gleixner" <tglx@linutronix.de>,
akpm@linux-foundation.org, "Ingo Molnar" <mingo@elte.hu>
Subject: Re: [PATCH] msleep() with hrtimers
Date: Thu, 9 Aug 2007 21:01:45 +0100 [thread overview]
Message-ID: <1158166a0708091301q1eca67ct2ef3fa81e3878510@mail.gmail.com> (raw)
In-Reply-To: <1158166a0708091231r21903840mc927b6baa47e4598@mail.gmail.com>
On 8/9/07, Denis Vlasenko <vda.linux@googlemail.com> wrote:
> On 8/8/07, Arjan van de Ven <arjan@infradead.org> wrote:
> > You keep claiming that hrtimers are so incredibly expensive; but for
> > msleep()... which is mostly called during driver init ... I really don't
> > buy that it's really expensive. We're not doing this a gazilion times
> > per second obviously...
>
> Yes. Optimizing delay or sleep functions for speed is a contradiction
> of terms. IIRC we still optimize udelay for speed, not code size...
> Read it again folks:
>
> We optimize udelay for speed
>
> How fast your udelay do you want to be today?
Just checked. i386 and x86-64 seems to be sane - udelay() and ndelay()
are not inlined.
Several arches are still frantically try to make udelay faster. Many have
the same comment:
/*
* Use only for very small delays ( < 1 msec). Should probably use a
* lookup table, really, as the multiplications take much too long with
* short delays. This is a "reasonable" implementation, though (and the
* first constant multiplications gets optimized away if the delay is
* a constant)
*/
and thus seem to be a cut-n-paste code.
BTW, almost all arched have __const_udelay(N) which obviously
does not delay for N usecs:
#define udelay(n) (__builtin_constant_p(n) ? \
((n) > 20000 ? __bad_udelay() : __const_udelay((n) * 0x10c7ul)) : \
__udelay(n))
Bad name.
Are patches which de-inline udelay and do s/__const_udelay/__const_delay/g
be accepted?
Arches with udelay's still inlined are below. mips is especially big.
frv has totally bogus ndelay().
include/asm-ppc/delay.h
extern __inline__ void __udelay(unsigned int x)
{
unsigned int loops;
__asm__("mulhwu %0,%1,%2" : "=r" (loops) :
"r" (x), "r" (loops_per_jiffy * 226));
__delay(loops);
}
include/asm-parisc/delay.h
static __inline__ void __udelay(unsigned long usecs) {
__cr16_delay(usecs * ((unsigned long)boot_cpu_data.cpu_hz / 1000000UL));
}
include/asm-mips/delay.h
static inline void __udelay(unsigned long usecs, unsigned long lpj)
{
unsigned long lo;
/*
* The rates of 128 is rounded wrongly by the catchall case
* for 64-bit. Excessive precission? Probably ...
*/
#if defined(CONFIG_64BIT) && (HZ == 128)
usecs *= 0x0008637bd05af6c7UL; /* 2**64 / (1000000 / HZ) */
#elif defined(CONFIG_64BIT)
usecs *= (0x8000000000000000UL / (500000 / HZ));
#else /* 32-bit junk follows here */
usecs *= (unsigned long) (((0x8000000000000000ULL / (500000 / HZ)) +
0x80000000ULL) >> 32);
#endif
if (sizeof(long) == 4)
__asm__("multu\t%2, %3"
: "=h" (usecs), "=l" (lo)
: "r" (usecs), "r" (lpj)
: GCC_REG_ACCUM);
else if (sizeof(long) == 8)
__asm__("dmultu\t%2, %3"
: "=h" (usecs), "=l" (lo)
: "r" (usecs), "r" (lpj)
: GCC_REG_ACCUM);
__delay(usecs);
}
include/asm-m68k/delay.h
static inline void __udelay(unsigned long usecs)
{
__const_udelay(usecs * 4295); /* 2**32 / 1000000 */
}
include/asm-h8300/delay.h
static inline void udelay(unsigned long usecs)
{
usecs *= 4295; /* 2**32 / 1000000 */
usecs /= (loops_per_jiffy*HZ);
if (usecs)
__delay(usecs);
}
include/asm-frv/delay.h
static inline void udelay(unsigned long usecs)
{
__delay(usecs * __delay_loops_MHz);
}
#define ndelay(n) udelay((n) * 5)
include/asm-xtensa/delay.h
static __inline__ void udelay (unsigned long usecs)
{
unsigned long start = xtensa_get_ccount();
unsigned long cycles = usecs * (loops_per_jiffy / (1000000UL / HZ));
/* Note: all variables are unsigned (can wrap around)! */
while (((unsigned long)xtensa_get_ccount()) - start < cycles)
;
}
include/asm-v850/delay.h
static inline void udelay(unsigned long usecs)
{
register unsigned long full_loops, part_loops;
full_loops = ((usecs * HZ) / 1000000) * loops_per_jiffy;
usecs %= (1000000 / HZ);
part_loops = (usecs * HZ * loops_per_jiffy) / 1000000;
__delay(full_loops + part_loops);
}
include/asm-cris/delay.h
static inline void udelay(unsigned long usecs)
{
__delay(usecs * loops_per_usec);
}
include/asm-blackfin/delay.h
static inline void udelay(unsigned long usecs)
{
extern unsigned long loops_per_jiffy;
__delay(usecs * loops_per_jiffy / (1000000 / HZ));
}
--
vda
next prev parent reply other threads:[~2007-08-09 20:02 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-03 18:37 [PATCH] msleep() with hrtimers Jonathan Corbet
2007-08-03 18:54 ` Ingo Molnar
2007-08-03 19:19 ` Roman Zippel
2007-08-03 19:46 ` Arjan van de Ven
2007-08-03 19:58 ` Roman Zippel
2007-08-03 23:53 ` Arjan van de Ven
2007-08-04 3:00 ` Roman Zippel
2007-08-04 19:19 ` Arjan van de Ven
2007-08-06 0:09 ` Roman Zippel
2007-08-06 0:43 ` Arjan van de Ven
2007-08-06 1:03 ` Roman Zippel
2007-08-06 5:39 ` Arjan van de Ven
2007-08-06 10:03 ` Roman Zippel
2007-08-06 10:20 ` Manu Abraham
2007-08-06 15:53 ` Arjan van de Ven
2007-08-07 10:40 ` Manu Abraham
2007-08-07 12:45 ` Roman Zippel
2007-08-08 4:15 ` Arjan van de Ven
2007-08-09 19:31 ` Denis Vlasenko
2007-08-09 20:01 ` Denis Vlasenko [this message]
2007-08-07 19:40 ` Andrew Morton
2007-08-07 23:16 ` Roman Zippel
2007-08-07 23:29 ` Andrew Morton
2007-08-08 3:47 ` Roman Zippel
2007-08-08 4:14 ` Andrew Morton
2007-08-09 22:31 ` Roman Zippel
2007-08-08 11:55 ` Andi Kleen
2007-08-08 11:09 ` Manu Abraham
2007-08-08 11:52 ` Andi Kleen
2007-08-08 11:59 ` Manu Abraham
2007-08-09 7:16 ` Andrew Morton
2007-08-09 15:08 ` [linux-usb-devel] " Alan Stern
2007-11-28 10:29 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1158166a0708091301q1eca67ct2ef3fa81e3878510@mail.gmail.com \
--to=vda.linux@googlemail.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=corbet@lwn.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=zippel@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).