linux-kernel - Re: [RFC PATCH]Multi-threaded Initcall with dependence support

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] [day] [month] [year] [list]

Message-Id: <200706040906.39594.sheng.yang@intel.com>
Date:	Mon, 4 Jun 2007 09:06:39 +0800
From:	Sheng Yang <sheng.yang@...el.com>
To:	Dave Jones <davej@...hat.com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH]Multi-threaded Initcall with dependence support

On Friday 01 June 2007 04:26, Dave Jones wrote:
> On Tue, May 29, 2007 at 09:47:53AM +0800, Yang Sheng wrote:
>  > On Tuesday 29 May 2007 06:52, Randy Dunlap wrote:
>  > > On Mon, 28 May 2007 15:03:10 +0800 Yang Sheng wrote:
>  > > > Why we need this:
>  > > >
>  > > > It can speed up the calling of initcalls, especially useful for some
>  > > > embed device.
>  > >
>  > > Can you give concrete example(s) of why we need this?
>  > > Any real configs/hardware where it helps and how much it helps.
>  >
>  > We didn't got the precise data at hand now, because we should build a
>  > complete stable initcall dependence relationship for it, but we can't do
>  > it now.
>  >
>  > But we have done a relative stable test in a common x86_64 machine, with
>  > 2 threads and one dependence relation(pnpacpi_init depends on pnp_init
>  > and acpi_init). The result is the time spending on initcall calling
>  > reducing from about _5s_ to _2s_ (make the kernel with the defconfig).
>  > We analyzed the dmesg and found the most of time was save by run
>  > ide_generic_init and piix_init in parallel.
>  >
>  > Of course the dependence in the test case is not sufficient, but the
>  > effect is shown.
>  >
>  > We think this patch would be very useful in some embed deviced which
>  > requires fast boot speed. Some server may benefit too because of it's
>  > long time for device initiation.
>
> If we decide to do this, we should also introduce a way to disable it
> at runtime with initcall=noparallel or something.  Why?


> Because right now when people say "my computer hangs during bootup"
> we can ask them to boot with initcall_debug and usually find out
> the last thing it did before it locked up.   If we parallelise this,
> the output will be a lot harder to decipher.

Thank you for the advice. I will introduce a parameter to do this. 

But what's about idea itself? I don't know whether people like this... It 
required a little more work on initcall writing. 

Maybe we could limit the multithread part in device_initcall? For it seems the 
most time consumed here, and the others in total just less than 1s(at least 
on my machine). 

Thanks. 
-- 
regards
Yang, Sheng
-
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/