Messages in this thread | | | Date | Mon, 18 Jan 1999 14:20:17 -0800 (PST) | From | David Lang <> | Subject | Re: Linux and physical memory |
| |
-----BEGIN PGP SIGNED MESSAGE-----
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/
| |