[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20100422094156.11b0e119.akpm@linux-foundation.org>
Date: Thu, 22 Apr 2010 09:41:56 -0400
From: Andrew Morton <akpm@...ux-foundation.org>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Alan Cox <alan@...ux.intel.com>, mingo@...e.hu,
linux-kernel@...r.kernel.org, Sreedhara DS <sreedhara.ds@...el.com>
Subject: Re: [PATCH] IPC driver for Intel Mobile Internet Device (MID)
platforms
On Thu, 22 Apr 2010 14:16:11 +0100 Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> > > +static inline int busy_loop(void) /* Wait till scu status is busy */
> > > +{
> > > + u32 status = 0;
> > > + u32 loop_count = 0;
> > > +
> > > + status = __raw_readl(IPC_STATUS_REG);
> > > + while (status & 1) {
> > > + udelay(1); /* scu processing time is in few u secods */
> > > + status = __raw_readl(IPC_STATUS_REG);
> > > + loop_count++;
> > > + /* break if scu doesn't reset busy bit after huge retry */
> > > + if (loop_count > 100000)
> > > + return -ETIMEDOUT;
>
> > This function has seven-odd callsites and is waaaaaaaay to fat and slow
> > to be inlined.
>
> Looking at the asm I'm not convinced.
I tried two version of gcc and both of them just refuse to inline
the function anyway.
If the function is changed to __always_inline, gcc will then inline it.
text data bss dec hex filename
inline 6182 960 1680 8822 2276 arch/x86/kernel/intel_scu_ipc.o
__always_inline 6582 928 1760 9270 2436 arch/x86/kernel/intel_scu_ipc.o
I agree with gcc ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists