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