linux-kernel - Re: [patch] enhance initcall

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	02 Apr 2007 10:00:59 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [patch] enhance initcall_debug, measure latency

Ingo Molnar <mingo@...e.hu> writes:

> so 93.6% of the allyesconfig bootup time is in 2.5% of the initcalls. If 
> they were fixed then an allyesconfig bzImage, which would be capable to 
> run on every PC known to mankind without any module whatsoever, would 

Assuming that every PC has enough memory @) Allyes is >35MB

> take around 10 seconds to boot up (which is acceptable for kernel bootup 
> time).

It might make sense to measure idle ticks vs busy ticks too.
If it's idle cycles perhaps things can be more easily fixed by multi threading
the initialization. If it's busy cycles perhaps they can be converted
into sleeping cycles.

Perhaps you should tell the individual maintainers for those?
If they still have one. A lot of them look like old hardware
where there might be no working ones left, perhaps just deprecation
would make sense.

> initcall 0xc1f5487d ran for 23083 msecs: pca_isa_init+0x0/0x143()
> initcall 0xc1f54fba ran for 17121 msecs: pcf8574_init+0x0/0x20()

e.g. those just look like bugs.

> initcall 0xc1f0c06f ran for 14710 msecs: net_olddevs_init+0x0/0x169()

That's many drivers initialized together for compatibility ordering reasons.

-Andi

-
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/