Linked by James Ingraham on Thu 12th Apr 2012 22:36 UTC
Linux I don't actually have a reason for trying to build a Linux kernel with the CONFIG_PREEMPT_RT patch set. There's no way I can even measure the impact of it. Still, I felt like having a "real-time" Linux box, and set out to make one. Little did I know how difficult it would be to even get started.
Thread beginning with comment 513936
To read all comments associated with this story, please click here.
simplifying and speeding up the process
by AnyoneEB on Thu 12th Apr 2012 23:22 UTC
AnyoneEB
Member since:
2008-10-26

The Linux kernel build process can definitely be a bit intimidating at first.

I am not sure why you needed the "O=/path/to/build_dir" option. I've never run across that before; maybe something different in your setup compared to the Debian systems I have built kernels on. Also, after the kernel is built, running make install, make modules_install, and update-grub should handle putting it into the /boot directory and adding it to the grub menu (not sure if update-grub is a Debian-specific tool). You shouldn't have to know about the filenames of everything. As the previous kernel should still be in your grub menu, there isn't much to worry about on whether it works or not: if not, just boot the old kernel and try again.

The kernel you compiled is huge and took a very long time to compile. I suspect this is because you used the Arch default config which (like any distro's configuration) has every driver you could ever possibly want. Kernel builds usually take a few minutes for me (on a Core 2, so it should be faster on your Core i7), but that's with only the drivers I actually use enabled (I vaguely remember some make option for detecting your hardware, but I don't know what it was or if it works well). Also, on a modern multicore, don't forget the -jn option to make where n is the number of processes to run in parallel. The recommendation I usually see is to use number of cores + 1, but I don't know what the actual best value is.

Reply Score: 5

fasteez Member since:
2007-03-13

I too noticed the far too long amount of build time. You're probably right about the modules, and I guess Vbox does not help here. It took my little core2duo (throttled 1.2-1.6G) 20 minutes.

With a core i7 machine I would go LFS just to see if GCC test suite can run under 20 minutes.

I didn't know about `make all` being coupled to LILO, always good to know.

Reply Parent Score: 1

froh Member since:
2009-03-01

I seem to remember an article where Linus Thorvalds argued why your grandmother needs to recompile her kernel. If there is a make option to just compile the modules that's actually loaded, that would drastically reduce granny's compile time.

Reply Parent Score: 1

AnyoneEB Member since:
2008-10-26

Ah, found it. It's called make localmodconfig: http://kernelnewbies.org/Linux_2_6_32#head-11f54cdac41ad6150ef817fd...

Reply Parent Score: 3

Valhalla Member since:
2006-01-24

Also, on a modern multicore, don't forget the -jn option to make where n is the number of processes to run in parallel. The recommendation I usually see is to use number of cores + 1, but I don't know what the actual best value is.

Yes, the first thing that struck me was 4 hours? On a core i7? Then I saw he wrote 'make', rather than 'make -j5'. Using only one core out of 4 is quite inefficient.

Reply Parent Score: 5

ingraham Member since:
2006-05-20

The "O=/path/to/build_dir" option just puts the output somewhere else. This isn't especially useful, but it made me feel better. I hate having all the source and binaries jumbled up.

Interesting to know about the compile time. It was longer than I expected, but not a LOT longer. I'll have to see what I can do to trim it down.

Note that I was in a virtual machine. My experience has been the a VM has virtually no impact on purely processor-intensive tasks, but I only gave the VM 1 processor, which is why I didn't use the -jn option.

Reply Parent Score: 2