linux-kernel - deps: update in regard to parallel initialization of static linked drivers

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 4 Sep 2015 11:18:18 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	linux-kernel@...r.kernel.org
Cc:	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
	Greg KH <gregkh@...uxfoundation.org>,
	Russel King <linux@....linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Grant Likely <grant.likely@...aro.org>,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>
Subject: deps: update in regard to parallel initialization of static linked
 drivers

Am 26.08.2015 um 14:28 schrieb Alexander Holler:
> Hello,

(...)

> Some numbers (5 boots on each board, without and with ordering drivers),
> all times are seconds.

(...)

> imx6q (armv7):
>
> unordered:
> 3.451998 3.418864 3.446952 3.429974 3.440996 (3.4377568)
> ordered:
> 3.538312 3.549019 3.538105 3.515916 3.555715 (3.5394134)

(...)

> Further improvements could be to initialize drivers in parallel (using
> multiple cores) and/or to use this stuff on x86 (ACPI) too (e.g. by using a
> minimal DT which just includes dependencies).

I've now made a quick implementation which uses multiple threads to 
initialize annotated drivers in parallel. It worked out of the box.

Here are the times (dmesg | grep Freeing) I've now measured on the imx6q 
(4 cores):

3.388273 3.399892 3.411615 3.410523 3.388802 (3.399821)

So it's now at least as fast as without ordering the drivers. Even on 
the one system where ordering didn't help without parallel 
initialization (likely because the unordered sequence of initcalls is 
already quiet good on that system, in comparison to the other systems 
I've tested).

And my current implementation for the parallel stuff is far from being 
perfect and can be optimized much more (enough to not post a patch 
here). In addition I've added another driver to my config since I 
measure the old times, so the new times are including one more 
initialization of a driver (it now calls 30 annotated (static linked) 
drivers at boot, most stuff is still in modules (and some not annotated 
static linked drivers) on that system).

Maybe this helps raising interest enough that someone else will test and 
maybe give some (reasonable, not about style) feedback on my patches.

> Regards,
>
> Alexander Holler

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