I syspect the biggest problem you will run into is that you have no way of
knowing when memory is allocated whether or not the memory needs to be
accessed from the kernel. If the memory is used by the program with no
system calls you can allocate it anywhere, but if memory is allocated,
used, and then later used as a output buffer for example, the data would
first need to be copied from the non-kernel accessable space to the kernel
accessable space then output. As this copy would have to be done by the
program it would break many (if not most) of the software that is out
there.
This added memory would also be of limited use becouse very few programs
need large amounts of memory that are not used (at some point) for input
or output.
David Lang
"If users are made to understand that the system administrator's job is to
make computers run, and not to make them happy, they can, in fact, be made
happy most of the time. If users are allowed to believe that the system
administrator's job is to make them happy, they can, in fact, never be made
happy."
- -Paul Evans (as quoted by Barb Dijker in "Managing Support Staff", LISA '97)
On Mon, 18 Jan 1999, Max wrote:
> Date: Mon, 18 Jan 1999 22:00:58 +0100 (MET)
> From: Max <max@Linuz.sns.it>
> To: Craig Milo Rogers <rogers@ISI.EDU>
> Cc: Andrea Arcangeli <andrea@e-mind.com>, linux-kernel@vger.rutgers.edu
> Subject: Re: Linux and physical memory
>
> On Mon, 18 Jan 1999, Craig Milo Rogers wrote:
>
> >>Why can't the kernel just map in its address space the pieces of RAM it needs
> >>for kernel code/data, and unmap them when done with them?
> >...
> >>Maybe that mapping/unmapping of memory in kernel address space is expensive,
> >>but I don't know. So I posted the question.
> >
> > Yes, the mapping/unmapping can be expensive, depending upon
> >the underlying hardware architecture. The code to implement it adds
> >complexity to kernel services and device drivers. It also introduces
> >another set of potential deadlocks and resource mismanagements.
>
> I wasn't talking about a pageable kernel, but about unmapping unused memory
> from kernel address space...
>
> Anyway, I thought about it a little more, and in my opinion something can be
> done. I don't know if it's better, if it is doable, etc. so I just throw it...
> of course it would apply only on i386 (and maybe on other 32-bit archs).
>
> The idea is:
> 1) give 1GB address space to the kernel and 3GB address space to user processes
> 2) map 1GB of RAM, or the whole RAM (depending on which is smaller) into kernel
> address space.
> 3) for memory pages needed by user processes use
> if possible the memory _not_ mapped by the kernel,
> else use the free part of the memory mapped also by the kernel.
>
> It doesn't seem TOO complex. You don't have a paging kernel at all, you don't
> have to change the kernel address space at runtime, you have up to 1GB real RAM
> availaible for kernel code/data, processes address space is 3GB
> and you have a simple "use this if possible, else use that" algorithm
> for deciding which pages of real RAM to map in processes address space.
>
> And you can use more than 960MB of RAM without too many problems,
> without changing anything in case you have less than 960MB.
>
> Maybe I missed something really simple that shows this can't be done,
> but in this case I'd like an explanation.
>
>
> Massimiliano Ghilardi
>
> ----------------------------------------------------------------
> | I have yet to meet a person who had a bad experience of Linux. |
> | Most have never had an experience. |
> ----------------------------------------------------------------
>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQEVAwUBNqOzoz7msCGEppcbAQGH0wf/fl45l6onotKSrIRenXuKBYF5IfOasmF4
qFmAKLOJJQ7AWnkGtbaS7xPTpbBXdRZQkDLkJuADD+IRL7qgN8r6ZRqB2mxLDdQk
OtPiFKWHCiBWvO17JVlrZnFNlqHH8nIVmEQbadHBZLYFcRfdCSCtz84eylVdUkwM
7Xe9BEL3w4dqV3sx1MA9n5hM01UNuISIpaiohyQ3jfYcmpNezVgCTeoLG6IzgCDx
7OKWPLTAzkMCvY1tUWiufvk7rT50l8cxbD/gR8G2SmkpgqVAZKH7KNBn3qU4MJM3
JoW9FoqhxI8L25z97HG9tdz2tYz3vpPRLgkPvzmFrN1k3IiKMY4obQ==
=i7xT
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/