Install 11 kernel without the overhead

Chris_H · Nov 25, 2014

Greetings,

I love the FreeBSD live/install image/DVD/... for installs, and utility purposes.

While I believe I understand the logic behind it. I really dislike the overhead the GENERIC kernel used, imposes. IMHO it doesn't make for the best experience for would-be, or first time users, coming from other OS's. So having remembered that it was possible to extract the kernel configuration from a kernel (if it was built in -- default for GENERIC), and that a couple of thoughtful replies got me the incantation. I wanted to build a (mostly) GENERIC, that didn't have all the overhead WITNESS*, and other constraints/performance killers, that are built in, by default. And while I've been on *BSD for ~25 years, and would like to think I know it all, I am all too frequently reminded, that's not the case.

So. I'd like to ask what others do, when attempting to squeeze additional performance out of their kernels. Mind you; I want this to be as close to GENERIC, as possible. This is more of an attempt to make a /boot/kernel.old, as an alternate kernel to boot from, on the install media. I have no trouble creating a "lean" kernel, tailored to the hardware it runs on.

Thank you for all your time, and consideration.

--Chris

wblock@ · Nov 25, 2014

Code:

include GENERIC
ident SUPERMEGAFAST

# use nooptions and nodevice to disable unwanted things

Chris_H · Nov 25, 2014

wblock@ said:

How do you store all of this invaluable information in your head, wblock@?! You never cease to amaze me.

Thank you!

--Chris

jb_fvwm2 · Nov 25, 2014

I tend to copy the GENERIC files elsewhere with extensions to the file, so that the newest one can be diff'd to the earlier one. Then, a kernel with the editing out done once, can simply be edited to a later version, adding and maybe subtracting. But there is some extra stuff compiled in from years back that is not in GENERIC; SC_HISTORY_SIZE for example.

wblock@ · Nov 25, 2014

Sometimes I write articles: Simplifying FreeBSD Kernel Config Files.

Chris_H · Nov 25, 2014

jb_fvwm2 said:
I tend to copy the GENERIC files elsewhere with extensions to the file, so that the newest one can be diff'd to the earlier one. Then, a kernel with the editing out done once, can simply be edited to a later version, adding and maybe subtracting.

Good advice, jb_fvwm2. I've used that strategy, as well.

jb_fvwm2 said:
But there is some extra stuff compiled in from years back that is not in GENERIC ... SC_HISTORY_SIZE for example.

Great bit of knowledge. Thanks, jb_fvwm2.

All the best.

--Chris

Chris_H · Nov 25, 2014

wblock@ said:
Sometimes I write articles: Simplifying FreeBSD Kernel Config Files.

LOL, and sometimes I read those articles. Looks like I need to visit them more often.

Thanks again, wblock@.

--Chris

Chris_H · Nov 25, 2014

Heh. Just ocurred to me, after reading /usr/src/Makefile. That SUPERMEGAFAST isn't a TAG for a "bloatless" kernel -- removing WITNESS*, INVARIANTS, DEBUG*, ... <BLUSH>

So. Looks like I'm still hunting for all the "performance killers". Be great if some sort of TAG could be created for just such a purpose. Maybe we could do that here, and it could be included in src?

--Chris

Chris_H · Nov 26, 2014

OK I've managed, after reading heavily through /usr/src/sys/conf/NOTES, /usr/src/sys/sys/sysctl.h, /usr/src/conf/options.amd64, and GENERIC. To come up with what I think will give a freatureful, but better performance GENERIC alternative. Suitable as a FreeBSD install DVD alternative. But I'm not quite sure how to deal with the following two lines in GENERIC:

Code:

makeoptions   DEBUG=-g     # Build kernel with gdb(1) debug symbols
makeoptions   WITH_CTF=1     # Run ctfconvert(1) for DTrace support

Sure. I could just comment them both in GENERIC. But that just means higher maintenance. So is it the same as the others? As in

Code:

nomakeoptions   DEBUG=-g     # Build kernel with gdb(1) debug symbols
nomakeoptions   WITH_CTF=1     # Run ctfconvert(1) for DTrace support

That just doesn't look right. I'm sure it's wrong. Maybe it's

Code:

nooptions   DEBUG=-g     # Build kernel with gdb(1) debug symbols
nooptions   WITH_CTF=1     # Run ctfconvert(1) for DTrace support

I don't know. Any input would be appreciated.

Thanks!

--Chris

zirias@ · Nov 26, 2014

I don't know, but I would leave those. They ensure you can have meaningful stacktraces WHEN the kernel ever panicks. They just increase the size of the binary a little but shouldn't have any impact on runtime performance...

Chris_H · Nov 26, 2014

Zirias. Thanks for the response. I've opted to leave out

Code:

DEBUG=-g

and

Code:

WITH_CTF=1

DEBUG=-g adds external debugging support (GDB) which, for my purposes, isn't of value. This is intended as a replacement for the 11-CURRENT install (boot only) DVD. So I can't justify those. I'll just comment them out, as well as add nooptions GDB.

Thanks again, Zirias, for taking the time to reply.

--Chris