Newsgroups: comp.os.minix
Subject: Re: Minix Tweaking
References: <372f8bb9.521876178@24.2.68.71> <7gocto$dtm$1@nusku.cts.com>
Organization: Rochester Institute of Technology, Rochester, NY
From: aje9383@osfmail.isc.rit.edu (Andrew Erickson)
NNTP-Posting-Host: grace.isc.rit.edu
X-Original-NNTP-Posting-Host: grace.isc.rit.edu
Message-ID: <373050b6.0@isc-newsserver.isc.rit.edu>
Date: 5 May 1999 10:07:50 -0500
X-Trace: 5 May 1999 10:07:50 -0500, grace.isc.rit.edu
Lines: 33
XPident: aje9383
X-Original-NNTP-Posting-Host: 129.21.3.100
XPident: Unknown
Path: star.cs.vu.nl!newsfeed.amsterdam.nl.net!sun4nl!remarQ-easT!supernews.com!remarQ.com!feeder.qis.net!news-peer1.sprintlink.net!news-in-west1.sprintlink.net!news.sprintlink.net!isc-newsserver.isc.rit.edu!aje9383
Xref: star.cs.vu.nl comp.os.minix:35458

In article <7gocto$dtm$1@nusku.cts.com>, Will Rose  <cwr@cts.com> wrote:
>mike dombrowski <legodude@home.net> wrote:
>: This is somewhat related to the FAQ posts but I'll ask it anyway. I
>: running Minix 2.0 on a 386sx/16 with 4mb ram and a 40mb hard disk.
>: I've modified the kernel for networking but that's it. Is there a way
>: to tweak the kernel to get more perfomance outta the machine?
>: Disabling the ram disk maybe? Thanks
>
>Dropping the ram disk will slow things down (not by much) since the
>/bin files will have to be loaded from disk.  Generally there's not
>much you can do to speed up Minix except to increase the cache sizes.
>See minix/config.h for details.

In my experience, trading off the ram disk for about the same amount of disk
cache is a *very* nice tradeoff.  You don't lose any RAM (compared to
previously), but the things which are actually used stay in RAM and the
stuff which isn't used doesn't.  The RAM disk is, after all, little more
than a manually-controlled immutable disk cache; making it an automatic,
dynamic cache does help.

In other words, dropping the RAM disk without doing anything else will slow
things down a bit, but dropping it and increasing the disk cache similarly
will end up speeding things up somewhat.  Other than that, there's not a
whole lot of easy things to do; one could improve the compiler's code
generation (or use a better compiler), rewrite slow programs to be more
efficient, redesign the file system to use different data structures
(B-trees rather than lists for directories?), use faster hardware, etc. etc.

>Will
>cwr@crash.cts.com

--Andrew Erickson, aje9383@grace.isc.rit.edu
Spam unto others as you would have them spam unto you.
