On 10/11/2011 12:36, Mark Tinguely wrote:
On 10/11/2011 11:12 AM, Alan Cox wrote:
On 10/10/2011 16:28, Wojciech Puchar wrote:
is it possible to force VM subsystem to operate on superpages when
possible - i mean swapping in 2MB chunks?
Currently, no. For some applications, like the Sun/Oracle JVM, that
have code to explicitly manage large pages, there could be some
benefit in the form of reduced overhead. So, it's on my "to do"
list, but no where near the top of that list.
Alan
Am I correct in remembering that super-pages have to be aligned on the
super-page boundary and be contiguous?
Yes. However, if you allocate (or mmap(2)) a large range of virtual
memory, e.g., 10 MB, and the start of that range is not aligned on a
superpage boundary, the virtual memory system can still promote the four
2 MB sized superpages in the middle of that range.
If so, in the mmap(), he may want to include the 'MAP_FIXED' flag with
an address that is on a super-page boundary. Right now, the
"VMFS_ALIGNED_SPACE" that does the VA super-page alignment is only
used for device pagers.
Yes. More precisely, the second, third, etc. mmap(2) should duplicate
the alignment of the first mmap(2). In fact, this is what
VMFS_ALIGNED_SPACE does. It looks at the alignment of the pages already
allocated to the file (or vm object) and attempts to duplicate that
alignment.
Sooner or later, I will probably make VMFS_ALIGNED_SPACE the default for
file types other than devices.
Similarly, if the allocated physical pages for the object are not
contiguous, then MAP_PREFAULT_READ will not result in a super-page
promotion.
As described in my earlier e-mail on this topic, in this case, I call
these superpage mappings and not superpage promotions, because the
virtual system creates a large page mapping, e.g., a 2 MB page table
entry, from the start. It does not create small page mappings and then
promote them to a large page mapping.
Alan
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
