linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: JF Martinez <jfm2@club-internet.fr>
To: Renaud.Lottiaux@irisa.fr, ebiederm+eric@ccr.net
Cc: linux-mm@kvack.org
Subject: Re: Is Linux kernel 2.2.x Pageable?
Date: Fri, 7 Apr 2000 23:44:13 +0200	[thread overview]
Message-ID: <200004072144.XAA00646@agnes.bagneux.maison> (raw)

> Renaud Lottiaux <Renaud.Lottiaux@irisa.fr> writes:
> 
> > Rik van Riel wrote:
> > > 
> > > On Tue, 4 Apr 2000 pnilesh@in.ibm.com wrote:
> > > 
> > > > Is Linux kernel 2.2.x pageable ?
> > > >
> > > > Is Linux kernel 2.3.x pageable ?
> > > 
> > > no
> > 
> > May you be a bit more specific about this ?
> > Can not any part of the kernel be swapped ? Even Modules ?
> > Why ? Just an implementation problem or a deeper reason ?
> 
> Modules can be removed.
> Pageable kernels are stupid, slow, & dangerous.
> 
> If you need a pageable kernel you have other problems.
> 

This is silly.  To begin with one of those slow, stupid & dangerous
kernels called VM was able to host 41400 Linux virtual machines on a
single mainframe.  Second: one of those slow, stupid and dangerous
kernels called MVS probably holds the world record for reliability and
in the 60s/70s was already managing entire BIG companies on boxes who
by today sxtandards are ridiculously underpowered.

However paging the Linux kernel would not be a good idea.  The reason
is that it is not big enough to give significant benefits so better
keep it simple.  During the eighties your average MVS had to manege
several hundred of interactive users plus some batch plus some
databases plus transactional processing.  Just holding the data
startuctures for all this load meant MVS grew until it used 8 Megs of
RAM.  The box had only 16 Megs of it.  Thus being able to page out
data structures associated with sleeping processes was mandatory.

Today on a 128 megs box a properly compiled and modularized Linux
kernel will be about 2 megs.  That is 1.5% of the memory.  It will be
bigger on bigger boxes (due to larger page tables) but it will still
use only a tiny fraction of the RAM.  It will grow when you add
processes but not enough to justify implementing a pageable kernel in
our days when RAM is so cheap.

-- 
			Jean Francois Martinez

Project Independence: Linux for the Masses
http://www.independence.seul.org

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

             reply	other threads:[~2000-04-07 21:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-04-07 21:44 JF Martinez [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-04-08 14:23 pnilesh
2000-04-08 19:42 ` John Alvord
2000-04-04 11:06 pnilesh
2000-04-04 11:26 ` Rik van Riel
2000-04-07 12:57   ` Renaud Lottiaux
2000-04-07 14:48     ` Eric W. Biederman
2000-04-04 11:43 ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200004072144.XAA00646@agnes.bagneux.maison \
    --to=jfm2@club-internet.fr \
    --cc=Renaud.Lottiaux@irisa.fr \
    --cc=ebiederm+eric@ccr.net \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox