Blaisorblade wrote: >> I've not seen much of this if any at all, the various caches that are in >> place for these lookups seem to function quite well; what we did see was >> glibc's malloc implementation being mistuned resulting in far too many >> mmaps than needed (which in turn leads to far too much page zeroing >> which is the really expensive part. It's not the vma lookup that is >> expensive, it's the page zeroing) > Even to this email, I hope Ulrich will answer. All I can say is that some of our guys tuning a big application on a customer's site reported seeing the VMA lookups being on the profile list. This was some huge Java program. It might be that every other page had a different protection, executable or not, read-only mmap etc. And data access for very non-local. I cannot say more since this was near to the end of the trials. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Attachment:
signature.asc
Description: OpenPGP digital signature
- References:
- [patch 00/14] remap_file_pages protection support
- From: [email protected]
- Re: [patch 00/14] remap_file_pages protection support
- From: Arjan van de Ven <[email protected]>
- Re: [patch 00/14] remap_file_pages protection support
- From: Blaisorblade <[email protected]>
- [patch 00/14] remap_file_pages protection support
- Prev by Date: Re: [patch 11/14] remap_file_pages protection support: pte_present should not trigger on PTE_FILE PROTNONE ptes
- Next by Date: Re: Too many levels of symbolic links
- Previous by thread: Re: [patch 00/14] remap_file_pages protection support
- Next by thread: Re: [patch 00/14] remap_file_pages protection support
- Index(es):
 |