On 07/10/2011 19:13, Alan Cox wrote: > On Thu, Oct 6, 2011 at 11:01 AM, Kostik Belousov <kostik...@gmail.com>wrote:
>> For one thing, this indeed causes more memory use for the OS. This is >> somewhat mitigated by automatic use of superpages. Superpage promotion >> still keeps the 4KB page table around, so most savings from the >> superpages are due to more efficient use of TLB. >> >> > You are correct about the page table page. However, a superpage mapping > consumes a single PV entry, in place of 512 or 1024 PV entries. This winds > up saving about three physical pages worth of memory for every superpage > mapping. But wouldn't the "conservative" superpages policy make it difficult in the OPs case to ever get promotions to superpages if he's touching pages almost randomly? > Similarly, mmap(..., MAP_PREFAULT_READ) on a large, memory resident file may > pre-map the file using superpage mappings. grep doesn't find this symbol in the sys src tree in 8-STABLE - nor it seems in /usr/include. But anyway, is there a mechanism which gives more guarantees than "may" (i.e. which forces this) - or if not, how hard would it be to add one? Some Linux-based "enterprise" software (including Java) use Linux-specific calls to allocate large pages directly.
signature.asc
Description: OpenPGP digital signature
