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
