Date: Wed, 20 Aug 2008 09:58:03 +0200
Message-ID: <s5h63pwnmno.wl%tiwai@suse.de>
From: Takashi Iwai <tiwai@suse.de>
To: Daniel Walker <dwalker@mvista.com>
Cc: Arjan van de Ven <arjan@infradead.org>,
       lkml <linux-kernel@vger.kernel.org>
Subject: Re: slower initcalls in -next
In-Reply-To: <1219179084.18104.11.camel@dhcp32.mvista.com>
References: <1219179084.18104.11.camel@dhcp32.mvista.com>
User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka)
 FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.2
 (x86_64-suse-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2494
Lines: 52

At Tue, 19 Aug 2008 13:51:24 -0700,
Daniel Walker wrote:
> 
> 
> I was testing out todays -next I saw fastboot was included, which got me
> interested so I made a  list of the slower initcalls. This was an
> allyesconfig on 32bit x86, which means these numbers are somewhat
> inflated w/ debugging enabled.
> The top 25 below,
> 
>   initcall ub_init+0x0/0x76 returned 0 after 49465 msecs
>   initcall rtrack_init+0x0/0xec returned 0 after 30529 msecs
>   initcall net_olddevs_init+0x0/0x129 returned 0 after 25032 msecs
>   initcall alsa_card_miro_init+0x0/0x19 returned 0 after 11562 msecs
>   initcall cadet_init+0x0/0x156 returned -1 after 3173 msecs
>   initcall mousedev_init+0x0/0x7d returned 0 after 2658 msecs
>   initcall pty_init+0x0/0x449 returned 0 after 1735 msecs
>   initcall tcpprobe_init+0x0/0xc3 returned 0 after 1388 msecs
>   initcall sermouse_init+0x0/0x1b returned 0 after 1274 msecs
>   initcall microcode_intel_module_init+0x0/0x43 returned 0 after 1247 msecs
>   initcall ipx_init+0x0/0xd7 returned 0 after 1014 msecs
>   initcall piix_init+0x0/0x29 returned 0 after 747 msecs
>   initcall raid5_init+0x0/0x37 returned 0 after 648 msecs
>   initcall init_rfd_ftl+0x0/0x14 returned 0 after 579 msecs
>   initcall param_sysfs_init+0x0/0x143 returned 0 after 522 msecs
>   initcall serial8250_init+0x0/0xef returned 0 after 507 msecs
>   initcall init_sc520cdp+0x0/0x1d8 returned -5 after 415 msecs
>   initcall isapnp_init+0x0/0xca6 returned 0 after 347 msecs
>   initcall pci_init+0x0/0x31 returned 0 after 308 msecs
>   initcall tty_init+0x0/0x19c returned 0 after 305 msecs
>   initcall ehci_hcd_init+0x0/0x9f returned 0 after 305 msecs
>   initcall alsa_card_sb8_init+0x0/0x19 returned -19 after 305 msecs
>   initcall uhci_hcd_init+0x0/0xd4 returned 0 after 297 msecs
>   initcall com90xx_init+0x0/0xd6f returned -5 after 293 msecs
>   initcall alsa_card_wavefront_init+0x0/0x52 returned 0 after 286 msecs

At least, all alsa_* calls are only for ISA devices, and I don't think
it's worth to optimize.  Changing such hardcoded delays could break
the running system easily.

However, some of the above are definitely interesting to investigate
as they are mostly built-in and affect almost all people.


thanks,

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