Maximize Desktop Speed
Note:
The specific commands used in this article are appropriate for the OpenSUSE distribution, but do vary from one distribution to another. Check your documentation for the specific commands you will need before trying to recompile your kernel.
Compiling your kernel isn't that difficult, but remember there's a distinct probability of hosing your machine and turning it into a paperweight. (Okay, that may be a bit of an exaggeration. In the worst case, you simply would have to re-install Linux, and you wouldn't lose your data.) In my case, I used the YaST administration tool and installed two kernels, so I could choose either of them at boot time, and if I destroyed one, I could reboot with the other one, re-install the broken kernel and keep trying.
You need some specific packages to do this: kernel-source (the source files for the actual kernel), gcc (the compiler), ncurses (for the menus) and bzip2 (used internally to create boot images). You also need to know a bit about your hardware. Use cat /proc/cpuinfo to see how many CPUs you have and their brands, and cat /proc/meminfo for RAM information (Listing 3).
Listing 3. You will need information about your CPU and RAM before recompiling your kernel.
$ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : Mobile AMD Athlon(tm) XP 2200+ [...some lines snipped...] $ cat /proc/meminfo MemTotal: 483488 kB MemFree: 11560 kB Buffers: 19888 kB Cached: 323408 kB SwapCached: 2768 kB Active: 166432 kB Inactive: 230396 kB [...more lines snipped...]
Start with a dry run and recompile the kernel without any changes, just to see if everything is set up okay. Working as root, do what's shown in Listing 4.
Listing 4. Do a dry run to ensure that you have everything you need for compiling the kernel.
cd /usr/src/linux make clean make make modules_install make install
The make processes will run for a while, and although they might produce some warnings, there shouldn't be any errors. If everything still is running okay after you reboot, it means you can start experimenting; you already did a kernel build. (If things did go seriously wrong, reboot with the other kernel, re-install the thrashed kernel, fix the problem, and try a dry run again.)
Tweaking the kernel is simply a matter of choosing the appropriate options from a (large) menu. As root, do the following:
cd /usr/src/linux make clean make menuconfig
and you will see a screen (Figure 1) with a menu full of hundreds of options, although luckily, you will have to change only a few of them.
If graphical interfaces are more your style, change the last command to make xconfig for a friendlier way of working (Figure 2).
The following are some of the options to change:
Under General Setup, uncheck Cpuset support.
Under Processor Type and Features, check Tickless System and High Resolution Timer Support. Select the right CPU type under Processor Family, so the compiled kernel code will be optimized for it, and uncheck Generic x86 Support, which is needed only for generic kernels. Choose the amount of RAM you have under High Memory Support. Check Preempt the Big Kernel Lock, and under Preemption Model, choose Preemptible Kernel (Low-Latency Desktop). Note that for a server machine, you should select the No forced preemption option. Under Timer Frequency, choose 1000 (standing for 1000H). Finally, if you have a machine with only one CPU, uncheck Symmetric multi-processing support. If you have two or more CPUs, check that box, and under Maximum number of CPUs, enter the correct number. (All this data comes from doing cat /proc/cpuinfo, as discussed previously.)
Under Block Layer, uncheck everything, unless you have disks larger than 2Tb.
Under Kernel Hacking, uncheck Kernel Debugging, Collect kernel timer statistics, Debug preemptible kernel and Write protect kernel read-only data structures.
After you are done selecting options, exit the configuration program (say “yes” to save the new kernel configuration) and then do the following:
make make modules_install make install
Watch for unexpected error messages; there should be none. You will need to wait, as when you did with the dry run. On my laptop, the complete process requires more than 30 minutes. If you get an error message, either go back to the menu to try to fix whatever was wrong, or reboot with your backup kernel, re-install the broken kernel, and try again. If everything is okay, simply reboot, and try out your new kernel.
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- New Products
- New Products
- The Pari Package On Linux
- Dart: a New Web Programming Experience
- This is the easiest tutorial
2 hours 15 min ago - Ahh, the Koolaid.
7 hours 53 min ago - git-annex assistant
13 hours 53 min ago - direct cable connection
14 hours 16 min ago - Agreed on AirDroid. With my
14 hours 26 min ago - I just learned this
14 hours 30 min ago - enterprise
15 hours 31 sec ago - not living upto the mobile revolution
17 hours 51 min ago - Deceptive Advertising and
18 hours 27 min ago - Let\'s declare that you have
18 hours 28 min ago






Comments
How to get rid of fonts?
OK, so 'xfontsel' shows I have over 10K fonts. Many of the families are clearly foreign languages, that came with install. How do I get rid of some of them? 'apropos font' was no help, and 'adept' indicated I didn't have any font packages installed. I use Kubuntu. 'man apt-get' didn't give me a clue about finding font packages. Suggestions? Thanks.
Wrong information about prelink
The section about prelink is incorrectly stating that...
Using prelink in this way obviously requires more disk space (for there will be a copy of every prelinked library within each executable file), but with the current large disks, this won't even be noticed.
This is complete rubbish ! The author is clearly confusing rewriting the relocation tables with hard-wiring the libraries in executables. The scheme set up by the author would turn all binaries into static linked programs. Nothing is less true ! As a simple peek at the man page (or even Wikipedia) reveals, only the relocation tables are rewritten such that when a library is loaded into memory, it's symbols sits at the right spot in the virtual memory, such that the calculation of the symbol locations no longer needs to be done, but is exactly there where the program expects them.
So prelinking does not use a single byte (apart from the lightweight checksum mechanism) more disk space.
Another blatant fault:
Include the -m option so prelink will try to conserve memory, if you have many libraries in your system (highly likely) and not a very large memory.
This has *nothing* to do with your actual memory, but with the 4GB virtual address space limit on 32bit systems ! It just means that, _if_ each library was used in a single program (and that's what prelink allows without the -m option), you'd exceed the virtual address space limit. The solution is to see which libraries are mutually exclusive linked and let them overlap in virtual memory, as they'll never occur at the same time in the same process.
This article is also quite mediocre in the section about compiling a kernel, you're supposed to know how many RAM your system has. Wrong again. It's perfectly safe/performant to turn on "High Memory Support (4GB)", even if you only got 1GB. And the instructions for compiling a kernel are of the lesser quality I've seen around. You, a daring non-kernel hacking user, should nowadays only install a kernel through your packaging system (like make-kpkg for Debian/Ubuntu) and not using the good old 'make' command, which might as well overwrite your current kernel image and leave your system in an unbootable state (for example, when initrd support has been omitted and your filesystem drivers are compiled as modules.)
This article had good intentions, but the proof reading (if any) clearly missed some faults.