I don't understand how you can have the kernel copy stuff to/from areas of
memory it does not have direct access to.
In the case of the DMA issue, the hardware cannot access >16Mb so it
needs an ouside process (the kernel) to move the stuff to where it can
access it. the kernel has direct access to everything and can move it as
needed.
almost need another process (memorykernel???) that would move the memory
around so that the kernel can access it.
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:45:06 +0100 (MET)
> From: Max <max@Linuz.sns.it>
> To: David Lang <dlang@diginsite.com>
> Cc: linux-kernel@vger.rutgers.edu
> Subject: Re: Linux and physical memory
>
> On Mon, 18 Jan 1999, David Lang wrote:
>
> >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/
>
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQEVAwUBNqPK/j7msCGEppcbAQFeUQf/bb931Kbiolxs8uoRkhac/xREZDvXfE2/
WZPl+hs6c9PgrOhcOOxeqLFYExUrLpUDQh5lGIAlHVY3Jk7OdKyhuUOjnGoFBOSH
AaLqT/Uj0mNAA+h6NU4PU/GQOssIc37zo4QbEatZK3TbkwvXdV77+J/vaHdjV+7/
d7QclKLF45PshR48eR2ZzA+uEVJAbl2TnM+oRoT30Eza/Of3vZ44+pzTfouNeJFr
IXEpgI5EBkaXuNIMEi2tNHgw0itkqVx+l9VYRLE2bluw6qMUQy23RPzQQye+8Za6
Ys4B5BmSl6Xk1sRphk8RlaXnLGHaKQRdQC1uRjOMD16qLTX4EFBtIg==
=Ejp9
-----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/