Re: [MiNT] virtual memory

[michael@mail.fastlane.net]

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

I hate English, even though I speak it as a first language.  Too many
back and forths.

I think I understand.  This global table will be part of all MMU tables created
for all processes.  In addition, the private MMU table per process will still
exist.  Rather than containing -all- information as it does today, though, all
entries not private will point off to the global table.  I just need to make
sure that private memory to a process and global memory of other processes
don't overlap.

In addition, I'll need to "block out" areas in the global table to ensure
that new global memory does not overlap existing private memory.  The blocked 
out area would also be a "preferred" area to place private memory for new
processes.

Is this right?

If so, let me go off and think about the implications for a bit.  If not,
please help me get it through my thick head.

If this is right, the up side is that, since a global table is needed,
my work was not in vain.  It may need to be modified a bit, but I think
most of the work needed to be done in either case.

Thanks,
Michael
michael@fastlane.net

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