Re: [PATCH 04/14] init: deps: order network interfaces by link order
From: Alexander Holler
Date: Mon Oct 19 2015 - 07:32:26 EST
Am 19.10.2015 um 12:57 schrieb Alexander Holler:
Am 18.10.2015 um 12:11 schrieb Alexander Holler:
Am 18.10.2015 um 07:59 schrieb Greg Kroah-Hartman:
On Sun, Oct 18, 2015 at 07:20:34AM +0200, Alexander Holler wrote:
Am 18.10.2015 um 07:14 schrieb Greg Kroah-Hartman:
On Sun, Oct 18, 2015 at 06:59:22AM +0200, Alexander Holler wrote:
Am 17.10.2015 um 21:36 schrieb Greg Kroah-Hartman:
Again, parallelizing does not solve anything, and causes more
problems
_and_ makes things take longer. Try it, we have done it in the
past and
proven this, it's pretty easy to test :)
Just because I'm curious, may I ask how I would test that in the
easy way
you have in mind? I've just posted the results of my tests (the patch
series) but I wonder what you do have in mind.
Use the tool, scripts/bootgraph.pl to create a boot graph of your boot
sequence. That should show you the drivers, or other areas, that are
causing your boot to be "slow".
So I've misunderstood you. I've read your paragraph as that it's
easy to
test parallelizing.
Ah, ok, if you want to parallelize everything, add some logic in the
driver core where the probe() callback is made to spin that off into a
new thread for every call, and when it's done, clean up the thread.
That's what I did many years ago to try this all out, if you dig in the
lkml archives there's probably a patch somewhere that you can base the
work off of to test it yourself.
Hmm, I don't think I will do that because that means to setup a new
thread for every call. And it doesn't need much imagination (or
experience) that this introduces quite some overhead.
But maybe it makes sense to try out what I'm doing in my patches,
starting multiple threads once and then just giving them some work. Will
After a having second thought on your simple approach to parallelize
stuff, I have to say that it just can't work because just starting a
thread for every probe() totally ignores possible dependencies.
Regardless if using one thread per probe() call or if feeding probe()
calls to just a few threads.
Maybe that's why previous attempts to parallelize stuff failed. But
that's just an assumption as I'm unaware of these previous attempts.
Or to describe it more verbose, if DEBUG is turned on in
init/dependencies.c (using my patches), it spits out a summary of groups
with initcalls (probe() calls) which are independent from each other and
therfore can be called in parallel. E.g. one of my systems this looks so:
[ 0.288229] init: vertices: 429 edges 204 count 170
[ 0.288295] init: group 0 length 66 (start 0)
[ 0.288329] init: group 1 length 33 (start 66)
[ 0.288364] init: group 2 length 13 (start 99)
[ 0.288398] init: group 3 length 7 (start 112)
[ 0.288432] init: group 4 length 9 (start 119)
[ 0.288466] init: group 5 length 8 (start 128)
[ 0.288500] init: group 6 length 11 (start 136)
[ 0.288534] init: group 7 length 6 (start 147)
[ 0.288569] init: group 8 length 4 (start 153)
[ 0.288603] init: group 9 length 8 (start 157)
[ 0.288637] init: group 10 length 3 (start 165)
[ 0.288671] init: group 11 length 2 (start 168)
[ 0.288705] init: using 4 threads to call annotated initcalls
That means the first group contains 66 initcalls which are called using
4 threads, and, after those have finished, the second group with 33
initcalls will be called in parallel (using the same 4 threads).
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/