[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] virtual memory



On Wed, Apr 19, 2000 at 10:57:10PM -0500, Michael White wrote:
> 
> Second, I thought to give each process its own context (which is what
> I think you were thinking of).  But, because of all
> the pointer passing that goes around, it would be quite difficult
> to set up each process with its private context with 4 GB of memory
> and not break anything.  And it would require too much work-around code.

Correct me if I am wrong, but I think with MP enabled, you can only pass
around pointers to memory areas which are allocated as "global".

That means that every process may have its own address space (for example,
starting at $01000000), and only the global part needs to be shared. The MMU
table for each process only needs to hold entries for the allocated memory
for that process plus the global parts.

How about this idea: every process gets its own address map, and malloc
starts allocating from virtual address $01000000. Global memory is allocated
from the end of the virtual memory space (ie. 4GB) growing downwards, and is
the same for all processes. Allocating virtual addresses for global memory
from the end enables us to easily share those (partial) tables between all
processes, so we don't need to copy any entries at all.

This gives us
 - a virtual address space of a bit less than 4GB *per process* (actually
4GB minus 16MB ST-RAM minus 64k I/O space minus the amount of global memory,
rounded up to a conventient block size that enables sharing the tables).

 - a fast task switch, which does not require fiddling with the MMU tables
at all (just rewrite the root pointers and fhush the TLB)


For system processes that need to access IO (or for processes that need to
write to PCI memory in Milan, which starts at $40000000, we would need to
decrease the top, but we would still have 1GB *per process* in the case a
dirty program needs to write to video memory on a Milan).

Since we do not need to manipulate MMU tables except on memory
(de)allocations, fragmenting them should be no problem. Finding free blocks
is easy: assuming 512MB of physical memory and 8k pagesize, we need a "free
page" bitmap of 65536 entries, which is 8k (or just one page in this
example).

Does this sound possible, or did I forget something?

cu
Michael
-- 
Michael Schwingen, Ahornstrasse 36, 52074 Aachen