compat-wireless: ridiculous build speed

compat-wireless: ridiculous build speed

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 330 bytes --]

Hi,

while watching compat-wireless-2009-06-11 doing baby-steps building all
its modules, I wonder what slows this down so horribly. No other
external module build package I know is that slow (I would say *at
least* one order of magnitude slower than normal). Is this really required?

[ Hurray, it's finished! ]

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: compat-wireless: ridiculous build speed

[Luis R. Rodriguez]

On Thu, Jun 11, 2009 at 2:29 AM, Jan Kiszka<jan.kiszka@web.de> wrote:
> Hi,
>
> while watching compat-wireless-2009-06-11 doing baby-steps building all
> its modules, I wonder what slows this down so horribly. No other
> external module build package I know is that slow (I would say *at
> least* one order of magnitude slower than normal). Is this really required?
>
> [ Hurray, it's finished! ]

I think the many depmod -ae are the culprit. This is in place to
account for all the crap of madwifi which may be present or older
drivers which have been renamed.

This could be improved. Patches are welcomed.

Ps. Try building with make -j 2, etc.

  Luis

Re: compat-wireless: ridiculous build speed

[Michael Buesch]

On Thursday 11 June 2009 20:48:13 Luis R. Rodriguez wrote:
> On Thu, Jun 11, 2009 at 2:29 AM, Jan Kiszka<jan.kiszka@web.de> wrote:
> > Hi,
> >
> > while watching compat-wireless-2009-06-11 doing baby-steps building all
> > its modules, I wonder what slows this down so horribly. No other
> > external module build package I know is that slow (I would say *at
> > least* one order of magnitude slower than normal). Is this really required?
> >
> > [ Hurray, it's finished! ]
> 
> I think the many depmod -ae are the culprit. This is in place to
> account for all the crap of madwifi which may be present or older
> drivers which have been renamed.
> 
> This could be improved. Patches are welcomed.
> 
> Ps. Try building with make -j 2, etc.

-j does not help. It will hardly build in parallel then. There's something
that serializes most of it (implicitly).

-- 
Greetings, Michael.

Re: compat-wireless: ridiculous build speed

[Luis R. Rodriguez]

On Thu, Jun 11, 2009 at 2:05 PM, Michael Buesch<mb@bu3sch.de> wrote:
> On Thursday 11 June 2009 20:48:13 Luis R. Rodriguez wrote:
>> On Thu, Jun 11, 2009 at 2:29 AM, Jan Kiszka<jan.kiszka@web.de> wrote:
>> > Hi,
>> >
>> > while watching compat-wireless-2009-06-11 doing baby-steps building all
>> > its modules, I wonder what slows this down so horribly. No other
>> > external module build package I know is that slow (I would say *at
>> > least* one order of magnitude slower than normal). Is this really required?
>> >
>> > [ Hurray, it's finished! ]
>>
>> I think the many depmod -ae are the culprit. This is in place to
>> account for all the crap of madwifi which may be present or older
>> drivers which have been renamed.
>>
>> This could be improved. Patches are welcomed.
>>
>> Ps. Try building with make -j 2, etc.
>
> -j does not help. It will hardly build in parallel then.

It works swell for me. The only thing that does not build in parellel
is the autoconf stuff but after its done with that step everything
builds as expected with -j 2.

> There's something
> that serializes most of it (implicitly).

You certain its just not the first part? I had written some patches to
make the first autoconf step into another step to then allow make -j
foo to work without a warning but that would involve another step. The
-j option does work for me though.

  Luis

Re: compat-wireless: ridiculous build speed

[Michael Buesch]

On Thursday 11 June 2009 23:10:52 Luis R. Rodriguez wrote:
> On Thu, Jun 11, 2009 at 2:05 PM, Michael Buesch<mb@bu3sch.de> wrote:
> > On Thursday 11 June 2009 20:48:13 Luis R. Rodriguez wrote:
> >> On Thu, Jun 11, 2009 at 2:29 AM, Jan Kiszka<jan.kiszka@web.de> wrote:
> >> > Hi,
> >> >
> >> > while watching compat-wireless-2009-06-11 doing baby-steps building all
> >> > its modules, I wonder what slows this down so horribly. No other
> >> > external module build package I know is that slow (I would say *at
> >> > least* one order of magnitude slower than normal). Is this really required?
> >> >
> >> > [ Hurray, it's finished! ]
> >>
> >> I think the many depmod -ae are the culprit. This is in place to
> >> account for all the crap of madwifi which may be present or older
> >> drivers which have been renamed.
> >>
> >> This could be improved. Patches are welcomed.
> >>
> >> Ps. Try building with make -j 2, etc.
> >
> > -j does not help. It will hardly build in parallel then.
> 
> It works swell for me. The only thing that does not build in parellel
> is the autoconf stuff but after its done with that step everything
> builds as expected with -j 2.
> 
> > There's something
> > that serializes most of it (implicitly).
> 
> You certain its just not the first part? I had written some patches to
> make the first autoconf step into another step to then allow make -j
> foo to work without a warning but that would involve another step. The
> -j option does work for me though.

Well, I never measured it, but I don't see any advantage when using -jX. Maybe
that is because forever equals forever+1.

What I do see, though, is that the per-cpu load is much higher when building the
kernel itself with the same -j parameter.

-- 
Greetings, Michael.

Re: compat-wireless: ridiculous build speed

[Gábor Stefanik]

On Thu, Jun 11, 2009 at 11:14 PM, Michael Buesch<mb@bu3sch.de> wrote:
> On Thursday 11 June 2009 23:10:52 Luis R. Rodriguez wrote:
>> On Thu, Jun 11, 2009 at 2:05 PM, Michael Buesch<mb@bu3sch.de> wrote:
>> > On Thursday 11 June 2009 20:48:13 Luis R. Rodriguez wrote:
>> >> On Thu, Jun 11, 2009 at 2:29 AM, Jan Kiszka<jan.kiszka@web.de> wrote:
>> >> > Hi,
>> >> >
>> >> > while watching compat-wireless-2009-06-11 doing baby-steps building all
>> >> > its modules, I wonder what slows this down so horribly. No other
>> >> > external module build package I know is that slow (I would say *at
>> >> > least* one order of magnitude slower than normal). Is this really required?
>> >> >
>> >> > [ Hurray, it's finished! ]
>> >>
>> >> I think the many depmod -ae are the culprit. This is in place to
>> >> account for all the crap of madwifi which may be present or older
>> >> drivers which have been renamed.
>> >>
>> >> This could be improved. Patches are welcomed.
>> >>
>> >> Ps. Try building with make -j 2, etc.
>> >
>> > -j does not help. It will hardly build in parallel then.
>>
>> It works swell for me. The only thing that does not build in parellel
>> is the autoconf stuff but after its done with that step everything
>> builds as expected with -j 2.
>>
>> > There's something
>> > that serializes most of it (implicitly).
>>
>> You certain its just not the first part? I had written some patches to
>> make the first autoconf step into another step to then allow make -j
>> foo to work without a warning but that would involve another step. The
>> -j option does work for me though.
>
> Well, I never measured it, but I don't see any advantage when using -jX. Maybe
> that is because forever equals forever+1.
>
> What I do see, though, is that the per-cpu load is much higher when building the
> kernel itself with the same -j parameter.

Actually, most of the slowness comes from stage 2 of the module build.
For me, stage 1 runs through rather fast (and -jX accelerates it quite
well), but stage 2 is serialized, and there is a long wait between
individual files. This wait is about a second on 2.6.28 for me in
vmware, but over 5 seconds (!!!) on 2.6.29. I've tried multiple
distros, and the time difference is consistent. (BTW stage 2 is
serialized in a full kernel build as well, though there is no reason
why it should be so; but no "wait" between steps is observed - in
fact, the second stage of a full 2.6.29 kernel build completes faster
for me than the second stage of compat-wireless on 2.6.29!)

-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: compat-wireless: ridiculous build speed

[Luis R. Rodriguez]

2009/6/11 Gábor Stefanik <netrolller.3d@gmail.com>:
> On Thu, Jun 11, 2009 at 11:14 PM, Michael Buesch<mb@bu3sch.de> wrote:
>> On Thursday 11 June 2009 23:10:52 Luis R. Rodriguez wrote:
>>> On Thu, Jun 11, 2009 at 2:05 PM, Michael Buesch<mb@bu3sch.de> wrote:
>>> > On Thursday 11 June 2009 20:48:13 Luis R. Rodriguez wrote:
>>> >> On Thu, Jun 11, 2009 at 2:29 AM, Jan Kiszka<jan.kiszka@web.de> wrote:
>>> >> > Hi,
>>> >> >
>>> >> > while watching compat-wireless-2009-06-11 doing baby-steps building all
>>> >> > its modules, I wonder what slows this down so horribly. No other
>>> >> > external module build package I know is that slow (I would say *at
>>> >> > least* one order of magnitude slower than normal). Is this really required?
>>> >> >
>>> >> > [ Hurray, it's finished! ]
>>> >>
>>> >> I think the many depmod -ae are the culprit. This is in place to
>>> >> account for all the crap of madwifi which may be present or older
>>> >> drivers which have been renamed.
>>> >>
>>> >> This could be improved. Patches are welcomed.
>>> >>
>>> >> Ps. Try building with make -j 2, etc.
>>> >
>>> > -j does not help. It will hardly build in parallel then.
>>>
>>> It works swell for me. The only thing that does not build in parellel
>>> is the autoconf stuff but after its done with that step everything
>>> builds as expected with -j 2.
>>>
>>> > There's something
>>> > that serializes most of it (implicitly).
>>>
>>> You certain its just not the first part? I had written some patches to
>>> make the first autoconf step into another step to then allow make -j
>>> foo to work without a warning but that would involve another step. The
>>> -j option does work for me though.
>>
>> Well, I never measured it, but I don't see any advantage when using -jX. Maybe
>> that is because forever equals forever+1.
>>
>> What I do see, though, is that the per-cpu load is much higher when building the
>> kernel itself with the same -j parameter.
>
> Actually, most of the slowness comes from stage 2 of the module build.
> For me, stage 1 runs through rather fast (and -jX accelerates it quite
> well), but stage 2 is serialized, and there is a long wait between
> individual files. This wait is about a second on 2.6.28 for me in
> vmware, but over 5 seconds (!!!) on 2.6.29. I've tried multiple
> distros, and the time difference is consistent. (BTW stage 2 is
> serialized in a full kernel build as well, though there is no reason
> why it should be so; but no "wait" between steps is observed - in
> fact, the second stage of a full 2.6.29 kernel build completes faster
> for me than the second stage of compat-wireless on 2.6.29!)

Heh yeah we need to fix this, patches are welcomed, I'll treat a beer sometime.

  Luis

[PATCH] Warp speed building

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3852 bytes --]

Luis R. Rodriguez wrote:
> 2009/6/11 Gábor Stefanik <netrolller.3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>> On Thu, Jun 11, 2009 at 11:14 PM, Michael Buesch<mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org> wrote:
>>> On Thursday 11 June 2009 23:10:52 Luis R. Rodriguez wrote:
>>>> On Thu, Jun 11, 2009 at 2:05 PM, Michael Buesch<mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org> wrote:
>>>>> On Thursday 11 June 2009 20:48:13 Luis R. Rodriguez wrote:
>>>>>> On Thu, Jun 11, 2009 at 2:29 AM, Jan Kiszka<jan.kiszka-S0/GAf8tV78@public.gmane.org> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> while watching compat-wireless-2009-06-11 doing baby-steps building all
>>>>>>> its modules, I wonder what slows this down so horribly. No other
>>>>>>> external module build package I know is that slow (I would say *at
>>>>>>> least* one order of magnitude slower than normal). Is this really required?
>>>>>>>
>>>>>>> [ Hurray, it's finished! ]
>>>>>> I think the many depmod -ae are the culprit. This is in place to
>>>>>> account for all the crap of madwifi which may be present or older
>>>>>> drivers which have been renamed.
>>>>>>
>>>>>> This could be improved. Patches are welcomed.
>>>>>>
>>>>>> Ps. Try building with make -j 2, etc.
>>>>> -j does not help. It will hardly build in parallel then.
>>>> It works swell for me. The only thing that does not build in parellel
>>>> is the autoconf stuff but after its done with that step everything
>>>> builds as expected with -j 2.
>>>>
>>>>> There's something
>>>>> that serializes most of it (implicitly).
>>>> You certain its just not the first part? I had written some patches to
>>>> make the first autoconf step into another step to then allow make -j
>>>> foo to work without a warning but that would involve another step. The
>>>> -j option does work for me though.
>>> Well, I never measured it, but I don't see any advantage when using -jX. Maybe
>>> that is because forever equals forever+1.
>>>
>>> What I do see, though, is that the per-cpu load is much higher when building the
>>> kernel itself with the same -j parameter.
>> Actually, most of the slowness comes from stage 2 of the module build.
>> For me, stage 1 runs through rather fast (and -jX accelerates it quite
>> well), but stage 2 is serialized, and there is a long wait between
>> individual files. This wait is about a second on 2.6.28 for me in
>> vmware, but over 5 seconds (!!!) on 2.6.29. I've tried multiple
>> distros, and the time difference is consistent. (BTW stage 2 is
>> serialized in a full kernel build as well, though there is no reason
>> why it should be so; but no "wait" between steps is observed - in
>> fact, the second stage of a full 2.6.29 kernel build completes faster
>> for me than the second stage of compat-wireless on 2.6.29!)
> 
> Heh yeah we need to fix this, patches are welcomed, I'll treat a beer sometime.
> 

Unless this comes with a regressing, consider the beer claimed.

------------->

Including config.mk again when kbuild called into the top level Makefile
slowed down the build process awfully. The reason for this were all the
dynamic, shell-based variable evaluations that were called over and over
again. Fortunately, including config.mk only in the outer Makefile run
appears to be enough. So let's remove this warp speed blocker.

Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
---
 Makefile |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 0ab7d27..49a786a 100644
--- a/Makefile
+++ b/Makefile
@@ -13,8 +13,6 @@ OLD_IWL=$(shell $(MODPROBE) -l iwl4965)
 
 ifneq ($(KERNELRELEASE),)
 
-include $(M)/$(COMPAT_CONFIG)
-
 NOSTDINC_FLAGS := -I$(M)/include/ -include $(M)/include/net/compat.h $(CFLAGS)
 
 obj-y := net/wireless/ net/mac80211/ net/rfkill/
-- 
1.6.0.2


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [PATCH] Warp speed building

[Hauke Mehrtens]

[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]

Jan Kiszka wrote:
> Including config.mk again when kbuild called into the top level Makefile
> slowed down the build process awfully. The reason for this were all the
> dynamic, shell-based variable evaluations that were called over and over
> again. Fortunately, including config.mk only in the outer Makefile run
> appears to be enough. So let's remove this warp speed blocker.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
> ---
>  Makefile |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 0ab7d27..49a786a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -13,8 +13,6 @@ OLD_IWL=$(shell $(MODPROBE) -l iwl4965)
>  
>  ifneq ($(KERNELRELEASE),)
>  
> -include $(M)/$(COMPAT_CONFIG)
> -
>  NOSTDINC_FLAGS := -I$(M)/include/ -include $(M)/include/net/compat.h $(CFLAGS)
>  
>  obj-y := net/wireless/ net/mac80211/ net/rfkill/

Hi Jan,

I have tested this patch and it reduced the build time for me from 3:30
to 2:40 minutes on a dual core system. I can not see any changes, expect
the reduced build time on my system. The resulting modules are still the
same.

Hauke


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 898 bytes --]

Re: [PATCH] Warp speed building

[Luis R. Rodriguez]

On Tue, Jun 16, 2009 at 11:39 AM, Hauke Mehrtens<hauke@hauke-m.de> wrote:
> Jan Kiszka wrote:
>> Including config.mk again when kbuild called into the top level Makefile
>> slowed down the build process awfully. The reason for this were all the
>> dynamic, shell-based variable evaluations that were called over and over
>> again. Fortunately, including config.mk only in the outer Makefile run
>> appears to be enough. So let's remove this warp speed blocker.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
>> ---
>>  Makefile |    2 --
>>  1 files changed, 0 insertions(+), 2 deletions(-)
>>
>> diff --git a/Makefile b/Makefile
>> index 0ab7d27..49a786a 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -13,8 +13,6 @@ OLD_IWL=$(shell $(MODPROBE) -l iwl4965)
>>
>>  ifneq ($(KERNELRELEASE),)
>>
>> -include $(M)/$(COMPAT_CONFIG)
>> -
>>  NOSTDINC_FLAGS := -I$(M)/include/ -include $(M)/include/net/compat.h $(CFLAGS)
>>
>>  obj-y := net/wireless/ net/mac80211/ net/rfkill/
>
> Hi Jan,
>
> I have tested this patch and it reduced the build time for me from 3:30
> to 2:40 minutes on a dual core system. I can not see any changes, expect
> the reduced build time on my system. The resulting modules are still the
> same.

Reason for including the config.mk is if your current kernel config
differs the makefiles won't pick up the new stuff.

  Luis

Re: [PATCH] Warp speed building

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1905 bytes --]

Luis R. Rodriguez wrote:
> On Tue, Jun 16, 2009 at 11:39 AM, Hauke Mehrtens<hauke@hauke-m.de> wrote:
>> Jan Kiszka wrote:
>>> Including config.mk again when kbuild called into the top level Makefile
>>> slowed down the build process awfully. The reason for this were all the
>>> dynamic, shell-based variable evaluations that were called over and over
>>> again. Fortunately, including config.mk only in the outer Makefile run
>>> appears to be enough. So let's remove this warp speed blocker.
>>>
>>> Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
>>> ---
>>>  Makefile |    2 --
>>>  1 files changed, 0 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Makefile b/Makefile
>>> index 0ab7d27..49a786a 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -13,8 +13,6 @@ OLD_IWL=$(shell $(MODPROBE) -l iwl4965)
>>>
>>>  ifneq ($(KERNELRELEASE),)
>>>
>>> -include $(M)/$(COMPAT_CONFIG)
>>> -
>>>  NOSTDINC_FLAGS := -I$(M)/include/ -include $(M)/include/net/compat.h $(CFLAGS)
>>>
>>>  obj-y := net/wireless/ net/mac80211/ net/rfkill/
>> Hi Jan,
>>
>> I have tested this patch and it reduced the build time for me from 3:30
>> to 2:40 minutes on a dual core system. I can not see any changes, expect
>> the reduced build time on my system. The resulting modules are still the
>> same.
> 
> Reason for including the config.mk is if your current kernel config
> differs the makefiles won't pick up the new stuff.

I had tested this before, and it did work nicely. To my understanding,
the 'export' in config.mk should carry all the defines into the nested
make calls.

Moreover, I'm surprised about this minimal reduction in Hauke's test.
Already running 'make clean' (no -j used for this) goes down from

    real    3m12.564s
    user    3m2.675s
    sys     0m8.461s

to

    real    0m20.670s
    user    0m17.337s
    sys     0m2.656s

here.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]