Re: [MiNT] Virtual Memory

[Eero Tamminen <oak@helsinkinet.fi>]

Hi,

On lauantai 12 tammikuu 2013, Eero Tamminen wrote:
> On lauantai 12 tammikuu 2013, Adam Kłobukowski wrote:
> > The problem is, whole GEM environment is designed in a way that makes
> > address space separation very hard if not impossible.

What if there wouldn't separate address spaces, just a global
pagemapping between physical RAM and addresses used by all processes
and (most of) the system?

I think not having separate address spaces would lose just abilities to:
- Have copy-on-write pages as that would mean previously shared
  page getting new physical address for another process
  -> as a result fork would still be as expensive as it's now
- Have memory mappings that are automatically expanded by OS, like stack on
  Linux.  They would be infeasible because without separate address spaces,
  extending stack would require global mapping, for a page following current
  stack end, to be unused.  In case of stack (which is allocated at program
  start), this is so unlikely that in practice it's impossible

However, I think global memory mapping should still allow page sharing
(without copy-on-write), memory mapping and demand paging, swapping,
zero pages (and memory protection like currently).

E.g. memory mapping the same file, like read-only text section of a binary
or shared library, would return same address for all processes, until all
processes have unmapped that file (section) i.e. ref counts for all
the pages in the binary/library goes to zero.


Ability to suffle pages around in physical RAM can significantly
reduce physical memory fragmentation and chance of system running out
of physical memory because there aren't large enough continous memory
areas available.

The global address space can still fragment, but as with 32-bit pointers
that's 2GB, much more than any existing Atari device offers, it's much
less of a problem.


> There are several applications for VM / paging.
> 
> Would all of these have issues with current GEM programs:
> 
> - file memory mapping and caching:
>   + one can easily process files that are larger than amount of RAM
>   + unix programs expect this
> 
> - concent of zero page (clean i.e. non-written memory not taking RAM,
>   except for few bytes needed for book keeping)
>   + can save a lot of RAM with programs that do large
>     pre-allocations without necessarily using all that memory
> 
> - swapping:
>   + one can run processes that take more memory than there's RAM
> 
> - shared libraries (needs file memory mapping):
>   + can save a lot of memory (but not in all cases)
>   + ABI compatible library upgrade not needing recompile helps with
> security
> 
> If swap algorithm isn't good, it can interact badly with memory
> mapping, you can enter swapping hell when some program processes
> large files, even if it wouldn't dirty the memory.


	- Eero