Sharing the same VM address space between Kernel and UserSpace

[Robert Watson]

On Tue, 15 Nov 2005, Peter Jeremy wrote:

> Avoiding other mappings isn't that difficult, though it's not totally 
> trivial.  You need to avoid KVA, stack, text, heap, shared libraries, 
> SysV SHM and other random mmap()'s.  If this is a fairly custom 
> application, you can get a fairly good idea of what other mappings exist 
> and just ensure that you pick an unused address and mmap it fairly 
> early.  If you need to allocate a very large region (getting towards the 
> GB region) or this is part of a library that is supposed to be linked 
> into arbitrary applications then things may be more difficult.

This used to be something of a problem in Coda, because we used RVM 
(Recoverable Virtual Memory) to provide transactional persistent virtual 
memory.  We required a large memory region (generally >128mb) that we 
could use at the same virtual address base over long runtimes and across 
reboots -- potentially years or more, since rewriting the memory region 
was a very expensive and complex process.  The VM space would get 
perturbed every few years due to migrations to ELF, etc, requiring 
conversion to new addresses.  The RVM code had to run early in process 
execution to prevent VM space fragmentation from becoming a problem also. 
I imagine that on 64-bit address space systems, life is much easier, but 
on 32-bit systems even in 1998 we had significant problems with this 
across many operating systems.

So not that it can't be done, but it can be a problem.  It might well be 
worth looking at the address usage in Coda to find some reference use, 
though, as Coda runs on a number of systems quite successfully, and uses 
RVM in both the client and server.

Robert N M Watson