Re: [MiNT] virtual memory

[Frank Naumann <fnaumann@freemint.de>]

Hello!

> That's not a bad idea, but I'm kind of concerned about finding
> free pages when the MMU table needs to grow.  The MMU table should
> ideally be contigous memory for easier swap algorithms, and if the
> pages are fragmented all over creation, it may become difficult.

No, the MMU table must be hold in physical memory, e.g. you can't put a
table to a already mapped place and use then.

And finding free pages is very easy, use a page from the free list or if
the free list is empty swap out a page. I can't see a problem.

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

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

> Several solutions came to mind.  First was to use the address range
> current occupied by physical memory.  But you can see that doesn't
> fix anything; it just shifts the problem around.  The address ranges
> will soon become as fragmented as the memory had.

Yes, and with one single address space we have the same problem forever.

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

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

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


Tschuess
   ...Frank

--
ATARI FALCON 040 // MILAN 060
-----------------------------------------
http://www.cs.uni-magdeburg.de/~fnaumann/
e-Mail: fnaumann@freemint.de