[PATCH] Warp speed building

[Jan Kiszka <jan.kiszka@web.de>]

[-- 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 --]