lkml.org 
[lkml]   [2015]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 04/14] init: deps: order network interfaces by link order
    From
    Date
    Am 19.10.2015 um 13:31 schrieb Alexander Holler:
    > 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).

    BTW. That also means that, for the above example, the worst case would
    mean an error rate of 61% if those 170 (annotated) initcalls would be
    started in parallel while ignoring dependencies.

    But that's just meant as an (hopefully) interesting number when looking
    at the above numbers a bit different.

    (I've understood that the patches aren't wanted.)

    >> Regards,
    >>
    >> Alexander Holler



    \
     
     \ /
      Last update: 2015-10-22 09:01    [W:3.614 / U:0.516 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site