>On Mon, 18 Jan 1999, Max wrote:
>>
>> 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.
>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.
Hmm. When a page is in a process address space, the kernel *can* access it,
at least as long as that process is the running one: access it from the
process' address space. If the process calls a write() or whatever else that
a) is blocking, so the kernel must choose another process to run
b) uses a buffer that the kernel must be able to access in order to complete
the call
then the kernel would need to copy the buffer in a part of RAM that it has
direct access to. It's annoying, but the same kind of things happens when
reading/writing memory through ISA DMA from/to pages above the 16MB limit:
the kernel has to do a copy from the pages above 16MB to some pages below 16MB,
which are DMA-able.
Change 16MB -> 1GB and you'll see it's the same problem.
The only difference is the 16MB limit is an hardware one,
while the 1GB limit is a software one.
>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.
I hope my example above solves this objection.
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/