Linux Optimization and Fine Tuning

Get rid of the bloat and extraneous programs that cut down on your system's responsiveness.

The body of this article is still being converted and will be available shortly.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.


Anonymous's picture

This guy sure gets lots of flack, especially about his compiler op stuff, however, it matches what's in that book which he recommends, and that book has benchmarks as well (though I didn't take a close look at them).

Any information along these lines is good - and there isn't much, not in one place anyhow - mere tidbits in various how-tos.

The kernel issue needs to be addressed - many today feel that it's a waste of time to recompile the kernel, I disagree. Besides the usual practice of removing support for outdated tech, what about mention of compiling your root filesystem directly into the kernel vs a module? This can eliminate the need for that "initial ram-disk" crap-o-la and is supposed to be more efficient, which I translate into speed.

Why are there not more documents like this? I want information! What about using the kernel feature to stripe swap files amongst different partitions? This is mentioned in the RAID how-to - anyone tried this?

Re: Linux Optimization and Fine Tuning

Anonymous's picture

My optimization tip: Use a 2 disk RAID array, it's not as expensive as SCSI and on average will half your disk access times; no need to do weird disk parameter tuning!! I did this with RH9.0 and now my box is just bitching.

Re: Linux Optimization and Fine Tuning

Anonymous's picture

next article will be by my mom, who apparently knows more than this guy without ever even HEARING of linux

Re: Linux Optimization and Fine Tuning

Anonymous's picture

same guy who wrote the previous comment bout -O3 being bull!

ok, who the heck wrote this guide, they aint done much research, because i can tell you now, you do not need mcpu, when using march. because mcpu is repected.

however I do agree with ya it is better to install from tarballs rather than rpm. (have to say something nice here)

little tips, if compiling glibc dont use -ffast-math, and if compiling kernel dont use no-force-addr.

Re: Linux Optimization and Fine Tuning

Anonymous's picture

Im sorry but -O9 is bull! -O3 is the highest you can go, but should you exceed this number then -O3 is used. Read the source of gcc and you'll find it has 'if number>=3 then ...'

apart from that it seems good, and for those who are compiling there is nothing wrong with using the -O3 option or attempting to fine tuning your machine. Ive taken mine to its absolute limits of optimization and aint had a problem, it took me several installs of many packages but I got there. Not recommended for those without patience.

Hdparm tweek slowed me down

Anonymous's picture

Warning on using that, now I dunno how to go back. :(

[root@viking aide]# /sbin/hdparm -tT /dev/hda


Timing buffer-cache reads: 128 MB in 0.91 seconds =140.66 MB/sec

Timing buffered disk reads: 64 MB in 3.47 seconds = 18.44 MB/sec

[root@viking aide]# /sbin/hdparm -c1 -d1 -m16 /dev/hda


setting 32-bit I/O support flag to 1

setting multcount to 16

setting using_dma to 1 (on)

multcount = 16 (on)

I/O support = 1 (32-bit)

using_dma = 1 (on)

[root@viking aide]#

[root@viking aide]# /sbin/hdparm -tT /dev/hda


Timing buffer-cache reads: 128 MB in 1.24 seconds =103.23 MB/sec

Timing buffered disk reads: 64 MB in 3.28 seconds = 19.51 MB/sec

Re: Hdparm tweek slowed me down

Anonymous's picture

Best thing to do is as follows:

If in X using a console window,
/sbin/hdparm -I /dev/hda

If in console mode X not started up at boot)
/sbin/hdparm -i /dev/hdparm

This will give you a detailed look not only at what your hard disk is currently set up for, but what it can handle. For example, many WD Caviar disks should have a -m 8 instead of a -m 16 flag.

-i and -I will also tel;l you what DMA modes your disk supports. There is an awesome article on hdparm at that is worth reading. It is page 6.12 inside the "Securing and optimizing linux" book posted there.

Check it out.

Re: Hdparm tweek slowed me down

Anonymous's picture

I bet you haven't read the man page. You really should run the -tT option three or four times and average the results. The difference between 140 and 103 is outside the normal variability that I have seen, however. That's probably a real loss. Notice that the buffered disk reads are faster; that change IS within the normal variance, so no significant gain there.

Next time you reboot, you will of course start over at whatever your distro had it at before. No need to wait for a reboot, though. Try /sbin/hdparm -c0 -d0 -m8 /dev/hda to turn those things off. Better yet, try man hdparm, and learn what it's doing BEFORE you fiddle with it!

I normally use /sbin/hdparm -c3 -d1 -m16 -u1 -??? /dev/hda (i.e., turning everything on!) for a four-times speed increase over all turned off, but results vary with hardware. Hdparm CAN DAMAGE HARDWARE, and you should READ THE MANPAGE!

Re: Hdparm tweek slowed me down

Anonymous's picture

Actully hdparm will work fine, and only some features of it are dangerous not all. That is part of the reason you use it to check the drive parameters first and then modify the command to suit your hardware (using UDMA is still dangerous (-X##), using DMA is not).

Either way though, this is pointless as a lot of distributions will determine this for you and set safe settings for your hardware (I know SuSE 7.x has done this for me, note that I don't mind paying for the software though).

Also, you can add the line to your startup scripts (rc.local in my case) and that will set the thing to your settings every time you reboot.

Re: Linux Optimization and Fine Tuning

Anonymous's picture

instead of saying "it's always better to install from tarballs", you could have gone into how you can add your optimization flags to your rpmrc file, and run a rpm --rebuild whatevver.src.rpm, get the improved benefits from compiling, and retain the oh so important dependancy information, and be able to easily remove/upgrade/whatever the package. Also, there's no disadvantage to all those kernel modules since they're not loaded (except lost hd space). and i need way more than 4 virtual terminals =P

Great the hdparm tuning !!!!

Anonymous's picture

I did the hdparm tuning and I saw 2 to 2.5 times better response in buffered disks reads with my SuSe Linux 6.4 box.

Thanks !!!

More tips

Anonymous's picture

- Try using Sylpheed instead of Balsa as a mail client.

Much much faster.

- ditch Gnome-session or KDE as fast as possible. (I use gnome's xsetroot replacement with a --draw&quit option to get a prettier background than blackbox will do. forget what it's called right now)

- Use top and shift-M to see what's hogging the memory.

- Use ROX filer. Lovely.

- Instead of startx, use xinit. ("ln -s .xsession .xinitrc" if needed) Saves a little memory. Also, why waste memory on xdm/gdm?

- Galeon for what lynx/links wont.

- Blackbox is the smallest (useable) WM I've found, but Fluxbox gives you a bit more for a small memory hit.

- Use console apps when you can (eg cdcd for cds, mpg123 in a script to 1/4 sample the mp3s, rexima for volume)

- Use rxvt instead of xterm

- The preemptible kernel patch is your friend.

- as much as possible that isn't needed to boot as modules in the kernel.

- 128mb swap partition keeps things from dying.

- Use that new Athalon 1900+ across the hall as an application server! "ssh -X bigmachine" and run the web browser with the other guys processor and memory! "echo $DISPLAY" should read like

I got my P75, 32mb (yea, I'd add more memory if the mo-board would let me) to load X and be useable in 28mb pretty comfortably without whacking anything too critical.

Re: Linux Optimization and Fine Tuning

Anonymous's picture

Jared Lyvers

First, I will agree w/ turning off anything that is unused. I for one have been a linuxfromscratch user ( ) since v2. It isn't one that I would tell my mother to use, but as for fine tunning, its the best way for me.

Also, kernels now use modules, not monolithic anymore.

ide drives, thats not for everyone, I have used hdparm and it has only once given anything worth talking about. If u want proformance, get a scsi drive.

then on to code optimization. -c9 ? I have always used -c2 and as one user stated, gcc tells u to not use over -c0 in order to not get compile errors.

However, I will have to agree w/ the startx therory, the X managers and the Virtual consols.

I have used blockbox for about 2 1/2yrs and have never looked back and on my workstation, I only have 2 Virtual consoles active. However, my 12 servers have all 6 VC's.

I will also have to agree w/ the HD partitioning. I don't do it like u do, but I also don't use one large partition for everything. Maybe that has to do w/ my starting on an Apple AIX Unix box, but tend to like




for workstations, and

but hey, thats just my $0.2 worth.

even more optimization

Anonymous's picture

I'd turn syslog first. What exacly you need it for on desktop machine ?

Second thing: fluxbox is missing among icewm and blackbox.

Third: use preemptive kernel patch from rml on desktop machine.

And the most importand: use distribuution, that has packages compiled for your arch. I use i686 PLD. Default cflags is -O2..

Re: even more optimization

Anonymous's picture

Syslog does very little - until you have a problem, then it becomes very useful. All sorts of stuff gets logged, and most of it is extremely useful in trouble-shooting. Even if you don't personally understand it others will. It seems a little silly to throw away one of the most useful trouble-shooting tools to gain a few miliseconds of processor time.

Improper use of hdparm can corrupt data

Anonymous's picture

The author's use of hdparm is incorrect. Not every hard drive supports the -m16 flag; Quantum and Maxtor drives specifically only support -m8. Newer hard drives handle incorrect -m flags gracefully, but some hard drives as old as a year will silently cause data corruption if the wrong -m flag is specified. Hardware damage can even happen with some drives! To determine the correct -m flag, use hdparm -i and look for the MaxMultSect setting. Use that setting as the suffix for the -m flag.

Using the -m and -d flags is unnecessary, though, with 2.4 kernels as they support setting the -m and -d flag automatically upon IDE drive initialization. The -c flag is *not* set automatically, though, and that brings up another of the author's incorrect uses of the hdparm command. The hdparm documentation states that very few IDE chipsets support the -c1 flag correctly and that the -c3 flag should be used in all cases. Using the -c1 flag can, again, result in silent data corruption. But, 32-bit IDE access (which is set by the -c flag) never yields any significant performance boost and can actually *decrease* performance in some high-load cases because IDE communicates along the ribbon (the cable connecting the IDE devices to your motherboard or IDE card) in 16 bits.

So, don't use hdparm! Using hdparm is unnecessary and can be dangerous w/o reading the documentation and knowing some details about how IDE and ATAPI works; 2.4 kernels set the appropriate optimizations, anyway, when it initializes the IDE drivers in the first place.

Re: Improper use of hdparm can corrupt data

viking's picture


Never use DMA enable on Alpha boxes. Twice I made mistake enable hdparm -d1 on hard drive. And face problem, file system dies unmountable.

Go tune mount option could be better.


Re: Improper use of hdparm can corrupt data

Anonymous's picture

You wrote: "The author's use of hdparm is incorrect. Not every hard drive supports the -m16 flag; Quantum and Maxtor drives specifically only support -m8." ... and ... "To determine the correct -m flag, use hdparm -i and look for the MaxMultSect setting."

As instructed, here's the output from hdparm -i on my Maxtor drive:
Model=Maxtor 91536U6, FwRev=VA510PF0, SerialNo=W605H8PA
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=30000096
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2
AdvancedPM=yes: disabled (255)
Drive Supports : ATA/ATAPI-4 T13 1153D revision 17 : ATA-1 ATA-2 ATA-3 ATA-4 ATA-5.

The lesson being -- qualify such statements.

You also write:
"Using hdparm is unnecessary and can be dangerous w/o reading the documentation"
What kind of silly c**p is that? Those who read the documentation are by defintion more informed than those that don't. Using a hammer can be dangerous, too. So yes, by all means, read documentation if you want to know more.

Re: Linux Optimization and Fine Tuning

Anonymous's picture

"To get the best performance from your machine, it would be a good idea to place the swap partition on the outermost track of your HDD. As a result of this, the Read/Write head can cover more area per revolution because the outermost track corresponds to the beginning of your drive."

This is incorrect!

Unlike CDs HDs have a constant number of sectors per track.

So although the head may cover more _area_, it will still cover the same number of _sectors_ (ie. same amount of data) per revolution.

It would probably be better to put the swap partition in the middle of a platter which _should_ result in lower average seek time to it.

The article in general is full of questionable advice. Compiling the kernel is not even recommended with -O3, not talking about any higher opto.

The author should do some research before giving out advice.


Re: Linux Optimization and Fine Tuning

Anonymous's picture would disagree with your statement. Every drive they benchmark shows a far higher data xfer rate on the outer tracks.

I am no disk drive geometry expert, BUT, I have used enough HD bench apps to know your information is wrong.

It seems you also should do a little research before opening your piehole

Re: Linux Optimization and Fine Tuning

Anonymous's picture

It is never smart to be rude. This article supports the position of the person you are insulting.

Why -O3 is harmful for kernel compiling Re: Linux Optimization a

Anonymous's picture

Modern disks have more sectors in outer than in inner tracks but nevertheless placing swap partitions at the beginning disk is still questionnable. The pattern usage of swap partitions involves short transfers between head movements. Therefore increasing throughput is less important then reducing seek time. It is better to place swap partitions at around the middle of the disk (but notice that the disk lies to fdisk about its true geometry and does not tell about outer tracks being bigger than inner ones so what looks to be the middle of the disk in fdisk is not the physical middle).

About -O3 for compiling kernel. I missed this when telling than the author was amateuristic. I should have been harsher Problem with -O3 is that in the case of kernel it makes it slower not faster. To understand why you have to remind that -O3 is in fact a shorthand for "-O2 -finline-functions".. A function call and later the return involve a sizable overhead so when function only executes a few instructions then inlining it will be much faster. However you have to keep in mind that if function is rarely used (example a function who is called just before exiting) then inlining it will provide no benefit but you will have made the program bigger and possibly slower due to an increase in cache and TLB faults. But compiler cannot know this: it knows the size of the function if there is a loop in it and if it is called from many places but only programmer knows if it will be called often. In 99% of programs using -O3 will make the program faster but when programmer has gone through the code and inlined the functions he knows will be frequently used then compiling with -O3 will result in compiler inlining additional functions the programmer left aside because he knew they were "dead functions". The Linux kernel is notorious for being one of those "hand-inlined" programs and thus should not be compiled with -O3.

Re: Linux Optimization and Fine Tuning

Anonymous's picture

"Unlike CDs HDs have a constant number of sectors per track.

So although the head may cover more _area_, it will still cover the same number of _sectors_ (ie. same amount of data) per revolution."

Never heard of ZBR? (Zoned Bit Recording)

Re: Linux Optimization and Fine Tuning

Anonymous's picture

Using swap partitions on different drives may overload the processor if you are using IDE disks. If you want to do this, you better go for SCSI, in which case, probably the drives and the adapter cost more than the 486.

Re: Linux Optimization and Fine Tuning

Anonymous's picture

The hdparm advice is irresponsible. If its not already enabled by default it may be for a good reason: some buggy hardware doesn't work correctly with DMA modes, most of which has (hopefully) made it into blacklists that the kernel can detect.

Users should never be tuning that sort of thing unless they are quite sure that they are using something that will work as expected. Fortunately, all the big commercial distros lately are good at figuring this out and enabling it. That doesn't excuse the bad advice or permit it to be codified into a flash-card-esque tip like the rest of this article, however.

A submit in ignorance and amateurism Re: Linux Optimization and

Anonymous's picture

I am frankly appalled when I read BS like this. Here is a guy who is giving advice on optimization but doesn't bother in MEASURING the effects or lack of effects and still believes in kernel compiling as an effective optimization mechanism

So let's start from the beginning: benchmarking.

For benchmarking no, you don't do what your average Linux article does: recompiling the kernel. Why? Because it depends on an application (GCC) who is very specific ((CPU intensive, zero FPU instructions, no threads, a memory use who could be very different from other applications). And I suspect many people who use kernel compiling as a benchmark don't even have the good sense to compile truly identical kernels ie with exactly the same drivers.

What you do is go to (Linux benchmarking suite).

Second: This guy doesn't even have read GCC doc. the -On flags are only a shorthand for a plethora of "small options" do a gcc -Vv -On to see them. Most of the options he recommends in conjunction with -O9 (BTW that combo has seen little test so you will play guinea pig) are already in -O9. And (because I ran benchmarks while preparing an article) I can guarntee that some of them don't play well together (ie using them in conjunction will slow your program. Finally he doesn't know the difference between -mcpu= (optimize for targets but using only 386 instructions) and -march= (optimize using the full instruction set). In gcc 2.9x and gcc 3.0x -march= will force -mcpu= at the same value. Of course this guu has not benchmarked -march= versus -mcpu= so he doesn't know that by using -march= you only gain a mere 2% at the expense of no longer being able to run your code on any IA32 box so unless there are parts written in assembler it is not worth the trouble.

Recompiling the kernel for optimization purposes is a non-sense. Since 1996 Linux has had technologies who allow vendors to ship kernels who are both complete and high performance, it is called modules. Also since installars can know about the CPU by parsing /proc/cpuninfo since 1998 competent vendors have been installing kernels compiled specifically for the right processor. The only people who would gain something would be K6 owners since vendors use Pentium kernels for K6 (due to its instruction set) but K6 is very different of a Pentium for optimization purposes.

And the memory savings? Not null but on a 64 megs you will save a whoopsing 1 to 1.5% of your RAM. It will have little effect on performance. We are no longer in 1992-1993 when people had 8 meg boxes (and kernel were not modular).

That kind of articles calling for recompiling the kernel have one effect: it gives bad image of Linux as a system where users hacve to spend days and perhaps weeks before being able to sart real work. It plays right in the hands of Microsoft. What we have to keep firmly in mind is: Since 1996 there is no reason to recompile kzernel if vendor did a good job, and if he did a bad one then the right answer is drop distro.

A submit in ignorance and amateurism Re: Linux Optimization and

Anonymous's picture

a bit strong... but thanks. your comment helps.

The real reason to recompile your kernel...

Anonymous's picture

Faster booting. For those who startup and shutdown linux regularly an optimised kernel may start a few seconds faster than the default one shipped by the vendor because it has less autodetection to do.

A submit in ignorance and amateurism Re: Linux Optimization and

Anonymous's picture

I tend to agree. Most of the tuning mentioned here seems very dated, and

aimed at desktop useage.

For more useful info for tuning modern linux based servers, the best

places to look are:

A submit in ignorance and amateurism Re: Linux Optimization and

Anonymous's picture

I agree with a lot of what your saying here, but compiling with -march is, IMO, a nice thing to do.

If I'm distributing aps that require a pentium class proc anyway, that 2% could very well mean a lot in performance - in Win/Linux benchmarks 2% is the difference between the winner and looser most of the time. I compile all code with the arch set to pentium/i586 - I could care less about 486's. There are other distros/apps for older hardware.

A submit in ignorance and amateurism Re: Linux Optimization and

Anonymous's picture

The problem here is that gcc 2.9x is not smart enough to optimize for P6 family (Ppro, PII, PIII, Celeron) while using Pentium instructions. You have to choose between using the full instruction set -march or optimize for target but using 386 instructions.

If you use -march=i686 then code will not run on Pentium, Pentium MMX, and K6s. I don't know about Athlon.

If you use -march=i586 then your code will run on Pentium (possibly not in the Cyrix 686 and some other processors who had Pentium speed but not its full instruction set) but problem is that it will be very slow on anything who is not a true Pentium. I have run some benchmarks on a PII, on a K6 and on a PIII and -march=i586 is 10 to 20% slower than -mcpu=i686 (and in addition the later will run on anytrhing)

Re: Linux Optimization and Fine Tuning

Anonymous's picture

OK article, some actions are useful others are not some depend on what you need and how your hardware is configured. For example, using multiple disks will help more than partitioning a certain way.

Another resource is

Re: Linux Optimization and Fine Tuning

Anonymous's picture

Some things that I did not see mentioned was the use of nice to improve responsiveness. My entire app menu is niced to some degree. Interactive tasks get niced between 0-5, processor intensive tasks that don't require interactivity get niced 16-19. Misc stuff falls into the 6-15 range.

Finally, processes that are really interactive pigs like X get niced to -10 or so.

You can also nice bdflush/kswapd and syslogd

to levels just outside the interactive tasks, say 6-8.

The article mentioned hdparm for the HD, but not the CD rom. One of my best tweaks was unmasking the IRQ for the CD rom. My system under heavy load, would stumble/skip during CD access. A real pain with MP3 or Vid playing. Unmasking that IRQ stopped that.

Also, elvtune/bdflush/kswapd can be tweaked depending on the use of the system. I have found many improvements that are task specific in bdflush and elvtune.

For general desktop use, larger caches, delayed flushes and a low lat Read to high lat Write elvtune seem best.

For a heavy I/O system, smaller caches, prompt flushes and a balanced high lat Read to Write elvtune give better throuput.

Through experimentation, I have found I can keep the system(cel 566/192) VERY responsive even when the load is hitting 8+, CS and IN=several thousand with 3 users.

I am running 2.4.17(linus tree) mono kernel compiled -O3

Re: Linux Optimization and Fine Tuning

Anonymous's picture

The hard drive advice failed on the machines I tried it on. I don't recommend it personally.

Re: Linux Optimization and Fine Tuning

Anonymous's picture


For Alpha Linux users, please don't turn on DMA support.. you'll face filesystem nightmare.


compiler flags

Anonymous's picture

uhm...a recent thread on kernel mailing list say that compiling linux kernel with anything more, that -o2 will lead to broken stuff, so don' use that flag for the kernel.

Re: Linux Optimization and Fine Tuning

Anonymous's picture

A couple comments:

Modern distributions use modular kernels. The modules are demand loaded, and typically the module for your hardware is listed in modules.conf, so the performance hit is insignifigant.

Nmap is nice if you're doing a security audit. It's not necessary otherwise. Likewise, the flags you're passing to netstat are not ideal for what you're trying to do. Try:

netstat -lnp --ip

You want -l instead of -a since you care ONLY about listening sockets in this case, not all. And daemons are going to be running on INET sockets, not UNIX, so you can filter down to just that with --ip.

When you're talking about a slower machine (which presumably is the point of this article) it takes a signifigant amount of time to type 'startx' and get the X server running.

In the case where the user uses the machine primarily as a desktop, and spends their time in X, runlevel 5 is the right choice. I myself am a commandline junkie and spend less than 1% of my time on virtual consoles.

I do agree with the idea of running a lighter window manager on machines with less RAM. Personally I'd suggest XFCE, which gives most of the benefits of a DE with a footprint comparible to a WM.

Likewise with links (or w3m or even the venerable lynx). Though the utility of text mode browsers is quickly being diminished by websites which use graphical or flash elements for navigation.

Each and every VC may take up resources... A whopping 64k of memory, to be exact. You can do it if you like, but the impact is so insignifigant, I wouldn't bother.

The hard disk tuning information is pretty good. But there was failure to mention that -m can be unreliable or dangerous on older hardware. In some cases drives with smaller buffers can only handle a setting of 4 or 8 before creating massive filesystem corruption.

Also, it would be worth noting that -u 1 is a nice addition. This allows the driver to unmask other interupts while processing disk requests, which should increase the responsiveness of the system. Be warned that certain chipsets have problems with the potentially higher latency introduced by this flag, so use with caution.

And if a disk is going to be used for large sequential files (mp3, video, etc) it can sometimes be useful to use the -a flag to increase read-ahead (default is 8, setting to 16 or 32 can help). Conversely, many small random seeks can sometimes benefit from dropping this to 2 or 4.

As for setting noatime... Well, on an extremely high volume filesystem (e.g. web server, mail spool) I can see it. Otherwise, don't bother. Buffered writes pretty well eliminate the performance benefit from this otherwise.


Re: Linux Optimization and Fine Tuning

Anonymous's picture

From kernel source package:

"In addition, please pay attention to compiler optimization. Anything greater than -O2 may not be wise. ..."

So I think that compiling the kernel in the suggested flags is

not reccomended

Re: Linux Optimization and Fine Tuning

Anonymous's picture

Definitely good to turn off unneccessary services and stuff. Still, there are programs that use up lots of memory and stuff. I suppose Galeon is probably just as much of a memory hog as Mozilla (since it uses the same page rendering engine), but since it uses the Gtk+ widget toolkit instead of the weird XP Toolkit (XP=cross platform) that is built into Mozilla, the interface feels a lot faster.

Linux heavily caches data into RAM, so I think it would have been appropriate to cover the files in /proc that are appropriate for tuning memory usage. While caching allows files to be read off the hard disk faster, and therefore contributes to program startup time, programs that are already running could probably benefit more from the physical RAM available in certain situations, rather than having it get pushed onto swap.

On that note, one of the best things you can do to make your system run faster/smoother is to add memory. There are exceptions to the rule (I had a P166 motherboard that would only cache memory (talking the processor L1,L2,L3 caches) up to 64MB, for instance), but things generally work out that way. Last I checked, memory was still cheap..

It's worth mentioning the preemptible kernel and low-latency patches floating around these days. They don't necessarily speed up actual processing, but they can often give a user the perception that things are running faster.

hdparm was a good thing to bring up, though I must say that I've generally only seen improvement in performance when turning on DMA support for IDE devices. The other stuff hasn't really mattered, in my experience.. The old ATA/PIO protocols for talking to IDE drives are utter junk, but DMA brings IDE performance much closer to what you'd get from SCSI. I still think SCSI is the way to go if you really want performance (though the cost is amazingly high).

In addition, IDE devices seem to work best when they have their own dedicated channel. If you have a motherboard with four IDE buses, try hooking up one device per bus. From what I understand, two IDE devices can't be talking at the same time. If you are writing data to one disk, you can't start doing something on the other disk until you're done with the write. Of course, `a write' could be as little as a few kilobytes, so it might not be all that big of an issue. This might affect people who are attempting to do software RAID with multiple IDE drives, though the problem may have gone away with the introduction of DMA..

Re: Linux Optimization and Fine Tuning

Anonymous's picture

Wrong! Galeon only uses a single jar file and also will use any plugins but that's about it.

Mozilla now, can seriously challenge Galeon performancewise.

Nothing will make IDE perform like scsi. IDE can only handle one i/o at a time compared to scsi's 250 so even if sustained data transfer is identical as seen here with ide and scsi drives at 7200rpm, it still will not handle multithreads which the hdparm tests will not reveal and the fact that scsi uses what is essentially a co processor freeing up cpu interrupts.

Of course, keep in mind that you run programs in memory, not off of the disk, unless you have small ram and are using swap. It all helps as a whole though, as you do load programs from disk and you don't want to wait too long for something to load and there is still some disk rw'ing with many programs.

nice article, wrong blackbox link

Anonymous's picture

great article for the newbie trying to get linux to run half-decently on a 486 with less than 16MB of RAM. most of the above responsdant didn't seem to understand who the audience was for this: users with little experience and even less hardware.

oh, and is no longer the active home page .. it has moved to ...


Anonymous's picture

A machine well-partitioned not only runs smoothly but also offers better security. I have seen administrators dump everything into one / partition. That, according to me, is a trict no-no.

Why? Why does it run more smoothly? Why is it better security? On a smaller machine I would argue that it is less efficient because the unused space can't be consolidated into a larger usable chunk.

The only downside I can see to a large partition is that corruption at exactly the wrong point could lose all your data (but this is why we have extra super-blocks).



Re: Partitions

Anonymous's picture

Mabye the choice of smoothly was not strictly intended. Having multiple paritions offers many advantages:

- better security due to attributes given to individual file systems

- improved data integrity as everything will not be lost when a FS hoses, regardless of the extra superblocks.

- helps keep directories from blowing up, if you have a 100GB drive w/ one partition and for whatever reason /var blows up, you may never know it. Yeah, a good admin would be watching, but...

- clean installs can be performed w/o dumping /home. Very nice if you toy around w/ diff distros and don't want to lose/restore your /home directories everytime you perform an install.

Maybe on a personal workstaion, one big FS is fine. But no way would I run boxen w/ only one FS ESPECIALLY servers!!!

Re: Partitions

Anonymous's picture

logs, you forgot to mention logs in specific. logs, on any system, but especially servers can royally get blown up to huge sizes if someone is trying to smack down your system by flooding the logs. An isolated /var/log is recomended for servers, I live with a /var for my workstations.

not having to nuke /home, and /usr/local is nice too for a fresh install. if you install a lot of tarballs and compile by hand, having a separate /usr/local is a good idea.

Its a mixed bag, you hve to plan ahead to do multiple partitions, but I've always been good at planning.

Re: Linux Optimization and Fine Tuning

Anonymous's picture

I prefer to make the first disk partition /boot. It helps on older BIOSes that can't deal with more than 1024 cylinders and is very convenient for switching between alternate root/usr partitions. /boot can be small, usally 20 - 80 meg is fine.
I follow /boot with a combined root/usr. With RAM cheap, I try to avoid swapping. As such I want the filesystem that I'm guaranteed to use to get the outer disk speed boost.
Add in /var, /tmp (unless using the shmfs soft /tmp), /home, etc. I put swap near the hub because it shouldn't happen much, if at all.
Mounting noatime is good to avoid excessive inode writes when compiling or web serving. Also consider adding noexec, nodev, and nosuid to those filesystems that don't need or shouldn't have such abilities. This will increase security. Unfortunately, several packages insist on creating and executing scripts in /tmp, and the PCMCIA card manager likes to create device nodes in /var, so watch out when setting those flags.
Good article. LJ should collect more tuning tips like this and come out with an enhanced version in the future.

Re: Linux Optimization and Fine Tuning

Anonymous's picture

i don't think that the tips in this article will help something on

most boxes:

- see the 'modular kernel' post

- of all the services the author mentions, there aren't a

lot of them that actually take up significant resources.

snortd does however. so everybody with more than 16

megabytes of RAM can ignore these, imho

- lots of partitions is not _always_ good. While it might

be a good thing on servers, for desktop machines only

one partition leads to a more efficient space usage (think

of a lot of small partitions, some being full and some being

empty) and thus less fragmentation.

- the 'return of the X manager' , 'use links', 'don't start X on boot'

... are about trading usability for speed, and the trades

the author proposes are not worth it imo. You don't gain

a lot of speed (starting X every time you need it makes working

even slower) but you loose a lot.

some might have a different opinion about 'the X manager' tho.

- 'reducing virtual consoles' , can be ignored by everybody with more

than 16 meg ram again imho.

- atime, might work, might not. i use 'noatime' to prevent

my disk spinning up all the time, and i doubt if there was

a significant speed gain.

Re: Linux Optimization and Fine Tuning

Anonymous's picture

Agreed for most of your post---except a few fine points:

> - lots of partitions is not _always_ good. While it might

> be a good thing on servers, for desktop machines

> only one partition leads to a more efficient space

> usage (think of a lot of small partitions, some being full

> and some being empty) and thus less fragmentation.

Indeed, I doubt that the "swap space at start" strategy is really a good one. I expect that most IDE drives these days are not doing constant angular velocity storage management.

> - 'reducing virtual consoles' , can be ignored by

> everybody with more than 16 meg ram again imho.

No. It should be ignored by everybody. Remember that most of the memory used by the already tiny program are actually shared by all instances, and also, as long as they won't wake up, they should all be using the swap soon after your memory is tight.

> - atime, might work, might not. i use 'noatime' to

> prevent my disk spinning up all the time, and i doubt if

> there was a significant speed gain.

There won't---unless your disk is continuously being accessed. This is because the OS does all the optimizations and will schedule disk writes when there is no other disk activity---unless there is real RAM shortage. Indeed, it is probably not a good idea to spin down disks and then have it back up every 20 or 30 minutes to start cron or something like that: the disk will go faulty much faster this way.


Anonymous's picture

Since when did gcc support anything beyond -O3? In fact even -O3 does not have any advantage over -O2 except inlining functions, which is often of doubtful use. (It's another matter that many people think -O2 causes miscompiled code sometimes, eg the FreeBSD project doesn't recommend anything beyond -O).

And the paragraph "Do you really need that X-rated stuff" seems unparseable to me -- I could make no sense of it whatever. It seems to be saying that "even" a GUI freak uses a console "only" 20% of the time (so console freaks use it less often?) so one should use startx rather than ctrl-alt-[function key].

Some of the other stuff is sort of meaningful. In a way. It doesn't tell you anything really interesting. The best tuning document I've read was FreeBSD's tuning(7) man page (written in May 2001 by a FreeBSD guru), I wish something like that existed for linux too. But even in a simple matter like "how much swap should you supply and where should you put it" Debian's documents conflict with Red Hat which probably conflict with SuSE's etc etc...

Re: -O9?

Anonymous's picture

>-O3? In fact even -O3 does not have any advantage >over -O2 except inlining functions,

This is simply not true. O3 makes a lot of difference if you use inline assembly for MMX things.

Re: -O9?

Anonymous's picture

>This is simply not true. O3 makes a lot of difference if you use inline assembly for MMX things.

Ouch. You loose locality and trash your cache. Nice differenze.


Only gcc-3.0 supports -O9