Re: [MiNT] virtual memory

[michael@fastlane.net]

Hi Frank!

> > My goals were simple - eliminate memory fragmentation and not
> > break anything. Memory protection currently provides
> > paged memory, so the hard part was done.
> 
> Sorry, with one address space you have the same memory fragmentation as at
> the moment. The address space is only bigger and not the physical
> available memory, that's all.

True enough, but with 4 GB I don't think you'll fragment that any
time soon.  At least not to a point where it's unusable.  

> > When memory becomes fragmented in a paged environment, it means
> > that you may have enough pages in total to run an application, but
> > not enough of the pages are in consecutive order.  But the MMU can
> > make them -look- like they are in consecutive order (as you probably
> > know).  But then the question hit me: so -where- do I put these pages?
> 
> I don't understand this question. A task have it's virtual address space.
> If he try to access a memory location a MMU table lookup is made to
> determine the real location. The table lookup will be ok or the table
> lookup fail. If the lookup fail there are mainly two reasons: the memory
> location the process try to access is not mapped (unused) or the memory
> location is swapped out.

Three reasons: The memory is unused, the memory is swapped out, or the
memory is private to another process.  The third reason is why the memory
flags need to be modified in some applications.

> > 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.
> 
> I don't see this so. First, we can share all address space that is not
> under the control of MiNT (I/O space) in the same way as global memory.
> For a new process we construct a new MMU table. The new table is clean,
> then we add the I/O space entries, then the global entries. At last we can
> do privat memory (this require real allocations: MEMREGION and some
> initial pages depending on the swapping algorithm).
> 
> In my eyes is much more difficult to handle one MMU tree with all
> applications and modify the MMU tree each context switch.

Each process has a memory flag to indicate the type of memory used
by that process on startup.  It's either prviate, global, read only,
or supervisor.

Assume worst case - all the processes running have memory that
is not private; it's either global, supervisor, or read only.  You start
up another process, and suppose its memory flags are set to "Read only".
If all processes have their own context, you must search for a memory
region that is available to -all- processes.

In this case, not only will each application have a huge page table,
but the memory fragmentation is even worse than with my solution of a
single, flat 4 GB model.  It will be split across page tables in
each process.
 
> > Finally, I decided to use unoccupied address ranges in a single MMU table.
> > The address ranges are not being used for anything.  And when I unmap the
> > free TT RAM pages, it increases the amount of unoccupied address space.
> > It also fixes the issue of shared memory.  Everyone uses the same MMU
> > table, so sharing is easy, whether through the shared libraries or through
> > setting of the memory flags of a program.
> 
> Shared memory is much more easier, it's defined as mmap() operation.

Again, though, I believe you'll need to find a commmon "free" address range
to map the memory into.  This address range must be free for any process
who will ever use the shared memory.  Especially if apps start passing 
pointers around.

> > Also, under the case where each process has it's own copy of the MMU
> > table, if a single process was created that required an addition
> > to the MMU table, it would require -all- processes to add that entry
> > into their MMU tables.  That could get ugly, as the MMU table would have
> > to grow for all processes.
> 
> I don't see this. Private memory is private for the task. No other table
> need to be touched. Global memory is shared by all processes. You only
> need to modify one table too.

But when memory is not private and not global, you have to modify every
MMU table for every process.  Read-only memory is read-only for all processes
-except- the owner.  Same thing for supervisor memory.

BTW Frank, this is an interesting discussion, and I'm glad I have to defend my
design.  It also brings out alternate solutions.  I get an uneasy feeling
if I present something fairly new and no one says anything.

Michael
michael@fastlane.net

---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/