Re: The Kernel (fwd)

[jfm2@club-internet.fr]

> 
> On 24 Jan 1998 jfm2@club-internet.fr wrote:
> 
> > I have looked at the patches in the Debian kernel and in them I found
> > the kernel config file so I was able to determine what is being
> > compiled in the kernel shipped with Debian.  They have compiled initrd
> > but nearly all the SCSI drivers are compiled in.  That makes little
> > sense to me.  Initrd is only of interest when you are booting with a
> > modular drive.  I also looked at networking features and most of them
> > are left out.
> 
> 
> It makes EXTREME sense to me ... I have a scsi system.  If get some
> corruption in that partition, I would not be able to repair it!
> 
> Some things should not be configured as modules ... things essential to
> being able to shut yor system down are among them.

If you drivers are compiled in then compiling initrd is only memory
wastage.  And don't be ridiculous about corruption.  If the initrd
file can be corrupted then there is no divine reason for your kernel
file not being a possible victim, so in this case floppies will be
your only hope.  Besides we are speaking about Linux not about a
Microsoft system: how many times have you seen a file corrupted when
not opened for writing?  (Files opened for writing are vulnearble to
power shortages).

> > 
> > I am basing in the 1.3.1 Debian found in Infomagic August.
> 
> Ok ... than is rather old.
> 
> The point is this ... there are too many possible points of failure in my
> opinion for an initrd boot to handle a modularized disk driver to suit me.
> As long as I can get linux loaded, I am ok with the current scheme.  In an
> initrd boot, if the script has been hosed by me or something else or the
> root image file is corrupted or the modules directory on the main
> partition is bad for some reason, I can not even run fsck to fix it, I am
> dead in the water.  I do NOT want to have the disk drivers that I need to
> run my system not available when I need them most ... to fix a screwup.
> 

Detail me these points of failure for the person having an initrd and
having left it untouched.  I remember you than all the initrd activity
takes place in a RAM disk ie it does not affect the file sitting on
disk.  A person rolling his own kernels will not be using initrd
anyway.  But a distributor not using it is nearly forcing his users to
recompile the kernel.  Not a thing we can accept in _this_
distribution.

> Besides ... lets get right down to it ... what difference is <1 meg going
> to amke any how and have you MEASURED the performance hit?  How many
> bogomips difference does it make?  I suspect that it will be miniscule.

Bogowhat????  In a discusion about a memory problem???  Oh God!  Are you
serious or are you taking me for an idiot?

> You might notice it on a 386 with 4mb of ram but a doubt that you will at
> all on a P166 (the slowest processor Intel is manufacturing right now)
> with 32MB of RAM (standard on systems for sale for Win95).
> 

No, he is serious, I simply cannot believe it!!!!

> As a matter of fact, I do not think you will see ANY performance hit ...
> the code is simply never called again after an initial probe (that
> granted, DOES take a few miliseconds).
> 

Now please pay attention for an _elementary_ lesson.  You have enough
made a fool of yourself.

1) Bogomips have nothing to do with our problem: we are speaking of
memory usage.  That is related with _SWAPPING_.  By reducing kernel
size you will make your machine faster when short of memory because
you will have lesser swapping.

2) Adding RAM or reducing the kernel size will have ZERO effect if all
your processes fitted in memory.

3) Bogomips is NOT a speed test, it is a CALIBRATION test.  Its goal
is to allow some drivers to measure time when precision is critical.
They are displayed for two reasons: -this allows you to know if the
turbo switch is on, -Linus chuckles when he sees people ridiculously
boasting about the Bogomips rating of their box: Bogomips means Bogus
Meaningless Indicator of Processing Speed

4) Bogomips will rate _exactly_ the same than you have 4 Megs or than
you have 1024, be your kernel small or big.  Kernel code is not
swappable to begin with.

5) Recompiling the kernel will not change your Bogomips rating except
in a nearly accidental fashion due to different memory alignment.

6) When you are very short of memory then your computer will begin
thrashing a situation where 99.999 % of the time is spent reading and
writing pages from the disk.  In a situation like this a 600 Mhz Alpha
will be only marginally faster than a 386 SX 16.


Now I could argue about the 32 Megs boxes and people not having a new
one so having 8 or 16 megs but I have had enough.

If you want to argue about kernel matters I suggest you a few readings
_BEFORE_ you continue:

-The Bogomips mini-Howto
-The files under the Documentation directory in the kernel source.
-The Unix system.  Bach.  ed Prentice Hall.
-The Design and Implementation of 4.4 BSD.  Leffler, MacKusic, Kostic 
  (ed Addison Wesley)
-Linux kernel internals.  Beck and al. ed Addison Wesley
-Operating system design.  Gavin and Silverschatz.  ed Addison Wesley.
-Programmation Linux 2.0.  Card and al. ed Eyrolles (this book is in french)
-Essential System Administration.  Aellen Frisch.  ed O'Reilly.

_After_ reading some of this, you will be able to argue _sensibly_
about kernel and kernel compiling matters.

-- 
			Jean Francois Martinez

==================== The Linux.  Use the Linux, Luke! =======================