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

Re: [MiNT] virtual memory



Hello!

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

It fragment faster as we can think :-) After some uptime it's fragmented
the same way.

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

The last doesn't apply if every task have it's own virtual adress space
(it's own table). The table of a task doesn't need to know about private
memory of other applications.

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

Read only and super user memory are principially the same as global memory
and can be handled exactly the same way. Only the page flag differ. So if
spoke about global memory I meant global, read-only and supervisor.

> In this case, not only will each application have a huge page table,

Every task have it's own table that only need to hold the process private
memory. Global (supervisor and readonly) memory is shared between all
tasks and all tables.

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

There is less memory fragmentation because every process have it's private
virtual address space. So task A can use virtual adress space from 0x0 to
0xfffff (for example) and task B can use virtual adress space from 0x0 to
0xfffff. As it's private memory there is no conflict as it's different 
virtual adress spaces.

Only global (supervisor and readonly) memory is affected from
fragmentation. But this is a conceptual problem.

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

No, shared memory doesn't work this way. Shared memory can be mapped to
different address regions for different applications. This is an elementar
functionality of shared memory and it's explicitly documented for MiNT
shared memory too. The current /shm of MiNT can be easily wrapped around 
mmap() I think.

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

Yes, and can be handled the same way as global memory. The page flag is
the only difference. The tables can be easily shared. This save every
overhead.


Tschuess
   ...Frank

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