Re: What's in kbuild.git for 2.6.19

From: Siddha, Suresh B
Date: Mon Aug 14 2006 - 15:14:09 EST

Keith, 2.4 kernel build doesn't seem to have this issue. Is this problem
specific to 2.6 kbuild?

"info make" says this.
Note that any job that is marked recursive (*note Instead of Executing
the Commands: Instead of Execution.) doesn't count against the total
jobs (otherwise we could get `N' sub-`make's running and have no slots
left over for any real work!)

Are we doing something different in 2.6 kbuild?


On Mon, Aug 14, 2006 at 12:02:09AM -0700, Keith Owens wrote:
>Sam Ravnborg (on Sun, 13 Aug 2006 21:45:03 +0200) wrote:
>>Outstanding kbuild issues (I should fix a few of these for 2.6.18):
>>o make -j N is not as parallel as expected (latest report from Keith
>> Ownens but others has complained as well). I assume it is a kbuild
>> thing but has no clue how to fix it or debug it further.
>It is the make jobserver code. make -j<n> causes the various make
>tasks to communicate and work out how many versions are currently
>running, to avoid overrunning the -j<n> value. Every recursive
>invocation of make subtracts one from the -j value, reducing the value
>that is left when make finally get down to doing some useful work
>instead of just recursing. Jobserver problems are yet another reason
>why recursive make is bad.
>kbuild is full of recursive make. The user cannot just add an excess
>to <n>, the number of recursive invocations changes from kernel to
>kernel as people try to fix bugs in makefile generation, so the
>required excess value keeps changing.
>Before somebody suggests it: the makefile cannot detect the supplied
>value of <n> and specify a modified -j<n> on recursive make commands.
>make will detect that a sub-make has -j<n>, complain about it and turn
>off the jobserver completely.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at