Linux Kernel in a Nutshell - FREE

[mzilikazi]

Nope not a joke.
http://www.kroah.com/lkn/

License
This book is available under the terms of the Creative Commons Attribution-ShareAlike 2.5 license. That means that you are free to download and redistribute it. The development of the book was made possible, however, by those who purchase a copy from O'Reilly or elsewhere.

[Lost Dog]

Nope not a joke.
http://www.kroah.com/lkn/

License
This book is available under the terms of the Creative Commons Attribution-ShareAlike 2.5 license. That means that you are free to download and redistribute it. The development of the book was made possible, however, by those who purchase a copy from O'Reilly or elsewhere.

I downloaded this the other day and spent last evening trying to strip down my 2.6.19.2 kernel to the bare minimum. It has some pretty good information on customizing the kernel.

I've got everything working except CDROM support (Pioneer DVR-111). I broke that somehow and now I'm trying to track down what I need to activate in the kernel to get it working again.

One thing I never knew was using the -j modifier during "make" to specify the number of threads to use. Speeds up compiling quite a bit with my dual core chip!

For compiling kernels I use make-kpkg rather than make but make-kpkg does not have the -j modifier. Is there something similar?

[garrincha]

At first I thought that it was the famed O'Reilly reference Linux in a Nutshell that I usually browse through whenever I'm in my local bookstore, but upon closer examination I was mistaken as it is about ikernel. Still, I downloaded the tarball, just read the first few chapters -- it is quite good and informative.

Thanks for the link mzilikazi.

[mzilikazi]

For compiling kernels I use make-kpkg rather than make but make-kpkg does not have the -j modifier. Is there something similar?

man make-kpkg
/snip/
CONCURRENCY_LEVEL
If defined, this environment variable sets the concurrency level of make used to compile the kernel and the modules set using
-j flags to the sub make in the build target of make-kpkg. Should be a (small) integer, if used. You can get the current num-
ber of CPUs using the command:
"grep -c '^processor' /proc/cpuinfo" WARNING: Do NOT set the -j option in MAKEFLAGS directly, this shall call the build to
fail.

So you could do:

Code: Select all

export CONCURRENCY_LEVEL=2
fakeroot make-kpkg blah blah blah

Or even add it to /etc/environment:

Code: Select all

LANG=C
CONFIG_SMP=y
CONCURRENCY_LEVEL=2

This is just what google told me. I don't even have access to a dual core machine to test on. Please report back if you don't mind.

[mzilikazi]

Just thought I'd toss this link in here for completeness. The Debian Linux Kernel Handbook.

[Lost Dog]

So you could do:

Code: Select all

export CONCURRENCY_LEVEL=2
fakeroot make-kpkg blah blah blah

Or even add it to /etc/environment:

Code: Select all

LANG=C
CONFIG_SMP=y
CONCURRENCY_LEVEL=2

This is just what google told me. I don't even have access to a dual core machine to test on. Please report back if you don't mind.

Ok, I just gave it a try... Before when compiling a kernel my CPU load would be near 90% on one kernel and 10% on the other it would fluctuate between the two. After using export CONCURRENCY_LEVEL both cores are pegged at 100%.

I need to write a little script that will export the time, start the compile then export the time once the job is done.... I could do that and compare the two and see a difference in compile time.

[ajdlinux]

I need to write a little script that will export the time, start the compile then export the time once the job is done.... I could do that and compare the two and see a difference in compile time.

i.e. something like the 'time' command?

[Lost Dog]

I need to write a little script that will export the time, start the compile then export the time once the job is done.... I could do that and compare the two and see a difference in compile time.

i.e. something like the 'time' command?

Actually, it's "date". The problem is getting the time output before and after the compile. At any rate, here are the results!

This is with a AMD X2 4400+ with 1 gig of memory.

I compiled the same kernel twice:

export CONCURRENCY_LEVEL=4
Start: 17:31:38
Finish: 17:36:02
Total time: 4 minutes, 24 seconds.

No CONCURRENCY_LEVEL set
Start: 17:37:48
Finish: 17:45:23
Total time: 7 minutes, 35 seconds.

NOT TOO BAD!

[ajdlinux]

I need to write a little script that will export the time, start the compile then export the time once the job is done.... I could do that and compare the two and see a difference in compile time.

i.e. something like the 'time' command?

Actually, it's "date". The problem is getting the time output before and after the compile. At any rate, here are the results!

'time' actually times the command given as an argument, so you could run it like:

Code: Select all

export CONCURRENCY_LEVEL=2
time fakeroot make-kpkg kernel_image

It would output in the form 'real, user, sys' and give the times.

[Lost Dog]

It would output in the form 'real, user, sys' and give the times.

I guess that would have been much easier than what I did

I just did another compile (finally figured out my CDROM issues and got that compiled in) and the result was about the same at 5 min 25 second (but this was compiling in some SCSI stuff as well).

[michael7]

Thanks for the link. I downloaded the book, read it and decided I wanted a copy. So, I ordered it from amazon for about $20. Heck, chapters 7 and 8 are worth that!

[graysky]

I usually don't like to bring up old threads, but for CONCURRENCY_LEVEL, it's my understanding that the number you assign should be one + "the number of cores."

For dual core chips:
# export CONCURRENCY_LEVEL=3

For quad core chips:
# export CONCURRENCY_LEVEL=5

I dunno about hyperthreading CPUs like the old P4 or new i7... maybe you'd want to treat each hyperthread as a core thus using a value of 9.

[BioTube]

4 seems to work well on my machine. Brings everything else to a (usable)crawl, but definitely speeds things up. Of course, I'm not too sure the effect of running too many concurrent jobs.