Re: Linux and physical memory

Jakub Jelinek (jj@sunsite.ms.mff.cuni.cz)
Tue, 19 Jan 1999 00:43:33 +0100 (CET)

> 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.

Read/write is a bad example, the kernel accesses there the user address
space (copy_{to,from}_user). But mapping all physical memory to kernel
address space is one of the essential design choices in the Linux kernel.
You cannot simply make a difference between user and other pages. Think
about e.g. COW. Which page would it access through user address space?
The source page or the destination? One would have to be mapped in kernel
space (Linux COW uses both source and destination here within the kernel
mapping of all virtual memory). You'd have to implement some API to map any
physical address not present in the static kernel mapping dynamically, some
way to cache the info on which page is mapped where and pollute the kernel
in several places with it (COW is not the only case). Also, that cache would
have to be probably per-task, as otherwise you'd have to modify all task's
kernel portion of page tables. Really, this thing does Linux right.

Also, Linux is not only for Intel. If you have some sane architecture, like
UltraSPARC or Alpha, you won't have such problems at all and polluting the
kernels with Intel hooks all around would only make things slower everywhere.
On UltraSPARC, the kernel does not even share the same address space with
userland programs, so with the exception of virtual page tables all virtual
address space is yours.

So, I think we should fix problems with io.h on Intel (decide on a
reasonable interface for memory mapped io accross all platforms - currently
there is none and you see the difficulties when you write a driver for more
than two different platforms), as otherwise PAGE_OFFSET at 0x70000000 works
for people just by luck and give the user (or kernel, see my btfixup patch)
the ability to lower PAGE_OFFSET. If you have more than say 3GB of RAM, you
can write a special block driver and use the rest of memory as swap (but I'd
suggest to buy some sane platform and use as many Gigs as needed without
trouble).

Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/
Linux version 2.2.0-pre7 on a sparc64 machine (3958.37 BogoMips)
___________________________________________________________________

-
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/