Blake Jones wrote: [snip] > To elaborate on this: part of the idea behind mmapfd() is that it gives > the kernel the flexibility to make global-scope decisions about where > and how a file should be mapped. This includes the appropriate page > size to use (which might vary depending on what platform you're running > on, or even potentially which CPU on a heterogeneous machine), what > virtual address to start the mapping at, how much padding to leave > between mappings, etc. Applications shouldn't have to know how the MMU > is designed in order to perform well, and we're trying to discourage > them from doing so. The auto-MPSS project already makes some decisions > about what page size to use; mmapfd() is just another step in that > general direction.
The problem is that (at least in the B72 installation on the Oct 2007 Summit's T2000 machine) the auto-MPSS stuff performs (IMO) poorly or does nothing - for example the only way to get the stack mapped with 64k pages was to use mpss.so.1 or memcntl(2) and the code didn't seem to use 64k pages at all (and libraries like libast are larger than 64k and ciuld benefit from something like that...). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
