public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
To: root@chaos.analogic.com, Timur Tabi <ttabi@interactivesi.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: What is the truth about Linux 2.4's RAM limitations?
Date: Tue, 10 Jul 2001 13:38:02 -0500 (CDT)	[thread overview]
Message-ID: <200107101838.NAA23636@tomcat.admin.navo.hpc.mil> (raw)

"Richard B. Johnson" <root@chaos.analogic.com>
...
> In Unix and Unix variants, it is by design, provided that the
> kernel exist within every process address space. Early Nixes
> like Ultrix, simply called the kernel entry point. Since it
> was protected, this trapped to the real kernel and the page-fault
> handler actually performed the work on behalf of the caller.
> 
> Unlike some OS (like VMS), a context-switch does not occur
> when the kernel provides services for the calling task.
> Therefore, it was most reasonable to have the kernel exist within
> each tasks address space. With modern processors, it doesn't make
> very much difference, you could have user space start at virtual
> address 0 and extend to virtual address 0xffffffff. However, this would
> not be Unix. It would also force the kernel to use additional
> CPU cycles when addressing a tasks virtual address space,
> i.e., when data are copied to/from user to kernel space.

I believe the VAX/VMS implementation shared OS and user space:

	p0	- user application		0
	p1	- system shared libraries	0x3fffffff
	p2	- kernel			0x7fffffff
		rest was I/O, cache memory	0xffffffff

It was a hardware design, not a function of the software.

UNIX origins were on a PDP-11. there were two sets of addressing registers
1 kernel, 1 user  (except on 11/45 - 1 kernel, 1 user, 1 "executive"
(never used except in some really strange form of extented shared library)

A full context switch was required. Kernel had to map a single 4KW window
to the user space for access to the parameters. Another 4KW window was used
to map the IO space. The remaining 6 mapping registers were used for supporting
the kernel virtual address. BTW, 1 KW = 2K Bytes, a mapping register could
map anything from 16 bytes to 8K bytes, if I remember correctly. The PDP 11
with memory management only had 16 mapping registers (8 user, 8 kernel) with
a maximum address of 64K bytes (16 bit addresses... my how far we've come).
The base hardware could only handle a maximum of 256 K bytes. More recent
cpu's expanded the size of the mapping registers (more bits/register) but did
not increase the number of registers. The last system (PDP-11/70 level) could
handle 4 MB of physical memory, but with all of the restrictions of the small
systems, just more processes were handled.

It was not possible to share memory between kernel/user other than that one
4KW window. The Linux 3G/1G split is a design choice for speed. It would still
be Linux even if it did 4G/0, just a different MM architecture with a lot
more overhead on intel x86 hardware.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

             reply	other threads:[~2001-07-10 18:38 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-10 18:38 Jesse Pollard [this message]
2001-07-10 19:14 ` What is the truth about Linux 2.4's RAM limitations? Mark H. Wood
  -- strict thread matches above, loose matches on Subject: below --
2001-07-11  4:31 alad
2001-07-10 21:49 Jesse Pollard
2001-07-10 22:07 ` Jonathan Lundell
2001-07-10 18:12 Jesse Pollard
2001-07-10 18:22 ` Jonathan Lundell
2001-07-10 18:28 ` Brian Gerst
2001-07-10 18:43   ` Chris Wedgwood
2001-07-10 19:35     ` Brian Gerst
2001-07-09 21:29 Jesse Pollard
2001-07-10 17:01 ` Timur Tabi
     [not found] <Pine.LNX.4.32.0107091250170.25061-100000@maus.spack.org.suse.lists.linux.kernel>
2001-07-09 21:03 ` Andi Kleen
2001-07-09 20:01 Adam Shand
2001-07-09 21:15 ` Brian Gerst
2001-07-09 21:18 ` Rik van Riel
2001-07-09 22:17 ` Matti Aarnio
2001-07-10 13:49   ` Chris Wedgwood
2001-07-10 17:03     ` Timur Tabi
2001-07-10 17:35       ` Richard B. Johnson
2001-07-10 18:01         ` Timur Tabi
2001-07-10 18:08         ` Jonathan Lundell
2001-07-10 18:45           ` Richard B. Johnson
2001-07-10 19:26             ` Jonathan Lundell
2001-07-10 23:56             ` Jesse Pollard
2001-07-10 20:19         ` Malcolm Beattie
2001-07-10  3:01 ` jlnance
2001-07-10  3:29   ` Michael Bacarella
2001-07-16  8:37   ` Ingo Oeser

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=200107101838.NAA23636@tomcat.admin.navo.hpc.mil \
    --to=pollard@tomcat.admin.navo.hpc.mil \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.com \
    --cc=ttabi@interactivesi.com \
    /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