Any ways to speed up linux?

[plug@arcticmail.com]

You failed to mention your CPU.  What seems slow to you?
Actions like starting up Mozilla?  How is your 400M of
RAM being used?  Is it mostly disk cache, or are you running
a large database server?  In general, this is probably not
a good idea (iow you should just let Unix' disk caching
do its thing), but if, for example, you wanted Mozilla to
load faster (and you have plenty of free RAM), you could
create a RAM disk, copy all of the Mozilla stuff to
the RAM disk, and run it from the RAM disk.

Another option if you have a 486 or Pentium* CPU would
be to recompile everything with gcc's -m486 to optimize
the code for a 486 instead of a 386.  I don't know if there's
a similar parameter to optimize for Pentium instead of
486 or 386.

There's a distro (Mandrake, I think) that offers both
i386 and i586 RPMs.  If you have a Pentium*, use the
i586 RPMs.

Else, you could try FreeBSD!  :)


D

* On Sat, Feb 17, 2001 at 01:38:08AM +0000, Rick Rosinski wrote:
> I don't mean to be long-winded, I just want to know if anybody had found any 
> tricks that makes a noticable difference in the speed of linux
> 
> I am looking for any way to speed up linux.  I have upgraded to the 2.4 
> kernel, and boot time takes less time.  Great.  If it improves the speed (and 
> smoothness) of programs in run-time, those hard drives are holding them back. 
>  So, I checked out some old PLUG mail and found stuff about the hdparm 
> utility (from "linux too slow") and I gave that a shot.  I found out that my 
> drives were already running in 32-bit mode - because the benchmark tests 
> yielded the same results.  I used "hdparm -Tt /dev/hda" to test the drive.  
> Then, I did a "hdparm -c3d1 /dev/hda".  This said that 32-bit dma was 
> activated.  Then I did hte hdparm -Tt /dev/hda again and the results were the 
> same.  I have 400 MB ram and two swap partitions totalling 267,544 MB, and 
> the swap is hardly ever used (using "free" and "kpm" (KDE Process Manager)).
> I tried to upgrade to XFree86 4.0.2, but the compilation forced out a kernel 
> bug in inode.c and that is too scary to try again (since inode.c is part of 
> the file management system) - and a crash that forced me to reformat a 
> partition.
> 
> -- 
> Rick Rosinski
> http://rickrosinski.com
> rick@rickrosinski.com