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

Re: [MiNT] Virtual Memory



Hi,

On lauantai 12 tammikuu 2013, Adam Kłobukowski wrote:
> W dniu 11.01.2013 18:52, Mark Duckworth pisze:
> > It looks like many features needed for virtual memory are implemented
> > as part of memory protection so this is likely an expansion of memory
> > protection.  It looks like the very first thing would be expand the
> > page_type and build a page fault handler.  As it is, I don't think we
> > were far from simple swap memory.
> 
> The problem is, whole GEM environment is designed in a way that makes
> address space separation very hard if not impossible.

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.


> To ease that, I suggest to 'divide' processes in two categories:
> 
>   - old style (all current programs) - all should live in one address
> space (with protected parts of AES&kernel)
>   - new style (new programs) - can have address space per process (I'd
> suggest a posibility to setup (on request) a fixed address window for
> all new style programs to be able to work with AES&VDI and old style
> programs
> 
> I'd also suggest that 'new style' programs should use ELF binary format
> and a separate compiler for them.

Btw. If one wants more common shared library format, but without MMU,
maybe formats used by ucLinux would be useful:
http://elinux.org/UClinux_Shared_Library#Using_Shared_Library_on_uClinux
?


	- Eero