Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Having a compiled module is not a limitation to performance, outside of wasted space on a storage device. Having a module that's not used loaded into RAM and managed by the OS means fewer resources for everything else. CPU cycles to check in on it, less RAM for other things.
I agree. But there's other stuff like probing for buses that are not there, and the like. Sometimes for certain combinations the boot may even be stalled if the kernel waits for some device probe to finish that wasn't even necessary. But yes, I agree that now this is not that much of a problem.
But the nice thing about linux is that MOST of the modules can be unloaded. And you can blacklist many of those so they don't automagically load at boot. So time spent making those modules an impossibility by excluding them isn't technically necessary. And the performance gains are not really earth shattering, +10% faster, isn't exactly twice or three times faster.
I agree. My point was that since I use pretty much 3 or 4 drivers total, that handle storage, networking and the rest, why build all of them if they're of no use to me? I mean, out of all the alsa drivers that are present in the tree, I use just the one. Why build all of them? But of course if some one wants to, there's no harm except maybe a few extra CPU cycles.
In the old days there were gains because you were compiling for your architecture instead of taking a literal i386 build in a 64 bit world. But these days the kernel is probably compiled for your actual chipset by default. So outside of low latency for audio, or special splash screen boot options, or something bleeding edge, the "need" to compile your own kernel is not something that most users of linux will encounter. It's still educational, and there may be some security concerns that make it desireable. But it's not really necessary for most use cases.
I agree. But why not use optimization if it's available? A finely tuned system never hurt anyone. It's really a matter of personal taste and some functionality, if you think about it. My old server still has limited RAM, so a tuned kernel really helps out there. My laptop is more recent, so any extra performance if available is just a sort of bonus
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
So what you're saying is I will likely see no benefit from compiling a custom kernel. That's what I'm saying too.
As I said in my first post on this thread people do not always do things for the reasons you do. Sometimes a quick, easy, solution is preferable in the circumstances and one was pointed out by Shadow_7. I also pointed to another one later on. This was because I felt that if saroj1439 has limited time or only wanted something specific from compiling a kernel then options should be given for that.
If your point is to compile a kernel that works for you in the shortest time, a very stripped down kernel helps. But the benefit is the compile time, not the result per say.
Most of my gains in performance these days is outside of kernel land. Like NOT using pulseaudio. Or using a lightweight wm like dwm or cwm instead of gnome or kde. Or using dwb instead of iceweasel for in browser based java games. And passing a lot of parms to disable filtering in mplayer.
A few K of RAM when the lowest end desktop for < $100 these days has 1GB or more of RAM is kind of moot. As I look at going ARM and dumping my 1.9GHz x86 dual core for a 2.7GHz quad core ARM that runs on 1/10th the power with twice the RAM.
You don't really need to compile the whole kernel to compile a single kernel module. The things we've forgotten since alsa was integrated with the kernel.
1. Don't have to look at 20 extra driver messages about hardware that I would not reasonably ever have. I disable building those drivers.
2. Customize to my exact CPU model.
3. To select the right driver for your Northbridge and Southbridge on the motherboard.
4. Enable the custom fixes for some motherboard faults and some buggy BIOS.
5. To enable CPU features that are not even in the huge kernel because of conflicts.
6. To enable some special modules for the kind of experimentation that I do.
7. To build modules for sensors, buses, and fan control.
8. CPU throttling, power options. There are more than the usual defaults.
9. Rid myself of init drive.
10. To build my hard drive filesystem into the kernel and make other filesystems modules.
11. To eliminate from the kernel all RAID and drivers for old disk types (RLE, etc.) that I will never have. Can keep SATA (and IDE because you may still have some for a CDROM or floppy).
12. Keep the floppy driver module as it is low cost.
13. Audio hardware, Internet driver, USB hardware (there are two kinds), and other motherboard built-in secondary interfaces can be modules.
There are several things that should not be disabled.
1. Always have your hard drive filesystem in the kernel, not as a module. This is usually ext2 (or 3).
2. If you run KDE, it has a security package that requires a kernel option that is not standard and actually seems to me to be experimental (at least in my encounter it was). xfce4 will run without it, but KDE will not.
(and I do not remember the exact name, but it adds caller information to syscalls).
3. UDEV has some strange requirements that need to be kept.
4. There are some boot complaints about devices that cannot be fixed (at least not by me).
5. You must have some internet modules even if you do not have internet because some programs use the internet stack within the machine.
6. If you have USB keyboard, your choices about USB will be different than if you use PS2 keyboard. Machine dependent, kernel dependent, and sometimes POM dependent, from what I hear.
Use the newbie config make option (which has explanations of what the config option does and some recommendations on when to turn it on or off).
Use the ? to see the explanation.
Check with the distribution default config. If you do not know why a config is set and you do not know what it is for, then there is a chance it will be bad to turn it off. Unfortunately there are a few like that but they are gotchas.
Last edited by selfprogrammed; 06-16-2014 at 03:29 PM.