Re: [uml-devel] memory

[Blaisorblade <blaisorblade@yahoo.it>]

On Monday 24 January 2005 11:02, Henrik Nordstrom wrote:
> On Sun, 23 Jan 2005, Rob Landley wrote:
> > The client kernel's highmem suport is unlikely to do much, I'd think.
> > Not unless it's unmapping and remapping multiple mmaps.
It does this, indeed and sadly (that's why it's so slow).
> > (There's large 
> > file support, but trying to mmap a 5 gig chunk out of a large file can't
> > work: what would that mean?  How could you generate an offset into the
> > last meg? What would the pointer _be_?)

> off_t is 64 bits in 64-bit file pointer mode, so there is no problem to
> mmap portions of an multi-gigabyte "ram" file within a 32-bit address
> space.

Offset can sure be 64-bit wide, but he refers to mmaping a 5G-wide chunk of 
memory, and to a "pointer offset"... you cannot mmap more than 4G in memory 
even with 4G/4G. Yes, you can do it like he says (i.e. mmapping back and 
forth).

> > The parent kernel's highmem support still doesn't provide more than 4
> > gigabytes per application, and the UML kernel is one application.

> Yes, but with HIGHMEM UML in theory can provide as as much ram to each
> single process running below it as it can for a single process. So yes,
> each process in the UML would still be limited, but the total RAM usage of
> UML would be practically unlimited. And in addition a very good
> environment for debugging HIGHMEM in general as you could set up things to
> only provide a very limited directly addressible address space with the
> rest remapped by HIGHMEM.

This point holds actually.

I think however that Henrik will agree that this is not yet implemented, and 
(maybe) nor in sight... about this, I would add somebody suggested 
using /proc/mm to this aim: since a single address space is not enough to map 
all the 64 Giga on a PAE system, he suggested using multiple address spaces 
and switching between them to use memory as cache for MySQL (IIRC)... this 
was also posted on this list.

Also, since x86_64 systems are so cheap (I'm writing from one of them), x86_64 
UML is going to be a reality soon, and we're in short of manpower, the 
logical conclusion is that this is unlikely to be implemented... unless it's 
very simple; do you think that making sure the offset inside /tmp/vm_file-*** 
is 64-bit wide would be enough?

> With HIGHMEM the host process size limitations has an direct effect on the
> maximum process size possible within the UML, but not on the RAM size of
> UML. In addition running an UML with HIGHMEM support does not depend on
> the host HIGHMEM support, but performance will obviously suffer if UML
> needs to swap..

> > (And that's with the 4 gig kernel/4 gig user patches from...  Ingo
> > Molnar, I think.)
I confirm
> > Highmem lets the system as a whole use PAE (up to 64 
> > gigs physical memory), but the kernel is basically doing something very
> > like the old DOS expanded memory behind the scenes, swapping around page
> > tables so each process sees a different set of physical memory. pages
> > (The overhead isn't quite so bad since it's doing that anyway as part of
> > protecting process's memory from each other...)

> Exctaly, and UML can do something very similar with the help of mmap().
Which is too slow, though...
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel