Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1250074 > unrolled thread

Re: [PATCH 04/14] init: deps: order network interfaces by link order

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 04/14] init: deps: order network interfaces by link order Alexander Holler <holler@ahsoftware.de> - 2015-10-18 07:00 +0200
    Re: [PATCH 04/14] init: deps: order network interfaces by link order Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-18 07:20 +0200
      Re: [PATCH 04/14] init: deps: order network interfaces by link order Alexander Holler <holler@ahsoftware.de> - 2015-10-18 07:30 +0200
        Re: [PATCH 04/14] init: deps: order network interfaces by link order Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-18 08:00 +0200
          Re: [PATCH 04/14] init: deps: order network interfaces by link order Alexander Holler <holler@ahsoftware.de> - 2015-10-18 12:20 +0200
            Re: [PATCH 04/14] init: deps: order network interfaces by link order Alexander Holler <holler@ahsoftware.de> - 2015-10-19 13:00 +0200
              Re: [PATCH 04/14] init: deps: order network interfaces by link order Alexander Holler <holler@ahsoftware.de> - 2015-10-19 13:40 +0200
                Re: [PATCH 04/14] init: deps: order network interfaces by link order Alexander Holler <holler@ahsoftware.de> - 2015-10-22 08:50 +0200

#1250074 — Re: [PATCH 04/14] init: deps: order network interfaces by link order

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.

Regards,

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1250081

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".

Hope this helps,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1250082

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.

> Hope this helps,

Unfortunately no, but thanks anyway. ;)

Alexander Holler

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1250084

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.

hope this helps,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1250103

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 
keep that in mind, also I don't think I will post any patch in the next 
few years. ;)

Regards,

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1250564

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.

Regards,

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1250579

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1253508

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web