On 25/03/15 12:22 PM, Vlastimil Babka wrote: > > I'm not sure I get your description right. The problem I know about is > where "purging" means madvise(MADV_DONTNEED) and khugepaged later > collapses a new hugepage that will repopulate the purged parts, > increasing the memory usage. One can limit this via > /sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none . That > setting doesn't affect the page fault THP allocations, which however > happen only in newly accessed hugepage-sized areas and not partially > purged ones, though. Since jemalloc doesn't unmap memory but instead does recycling itself in userspace, it ends up with large spans of free virtual memory and gets *lots* of huge pages from the page fault heuristic. It keeps track of active vs. dirty (not purged) vs. clean (purged / untouched) ranges everywhere, and will purge dirty ranges as they build up. The THP allocation on page faults mean it ends up with memory that's supposed to be clean but is really not. A worst case example with the (up until recently) default chunk size of 4M is allocating a bunch of 2.1M allocations. Chunks are naturally aligned, so each one can be represented as 2 huge pages. It increases memory usage by nearly *50%*. The allocator thinks the tail is clean memory, but it's not. When the allocations are freed, it will purge the 2.1M at the head (once enough dirty memory builds up) but all of the tail memory will be leaked until something else is allocated there and then freed. >> I think a THP implementation playing that played well with purging would >> need to drop the page fault heuristic and rely on a significantly better >> khugepaged. > > See here http://lwn.net/Articles/636162/ (the "Compaction" part) > > The objection is that some short-lived workloads like gcc have to map > hugepages immediately if they are to benefit from them. I still plan to > improve khugepaged and allow admins to say that they don't want THP page > faults (and rely solely on khugepaged which has more information to > judge additional memory usage), but I'm not sure if it would be an > acceptable default behavior. > One workaround in the current state for jemalloc and friends could be to > use madvise(MADV_NOHUGEPAGE) on hugepage-sized/aligned areas where it > wants to purge parts of them via madvise(MADV_DONTNEED). It could mean > overhead of another syscall and tracking of where this was applied and > when it makes sense to undo this and allow THP to be collapsed again, > though, and it would also split vma's. Huge pages do significantly help performance though, and this would pretty much mean no huge pages. The overhead of toggling it on and off based on whether it's a < chunk size allocation or a >= chunk size one is too high. The page fault heuristic is just way too aggressive because there's no indication of how much memory will be used. I don't think it makes sense to do it without an explicit MADV_NOHUGEPAGE. Collapsing only dense ranges doesn't have the same risk. >> This would mean faulting in a span of memory would no longer >> be faster. Having a flag to populate a range with madvise would help a > > If it's a newly mapped memory, there's mmap(MAP_POPULATE). There is also > a madvise(MADV_WILLNEED), which sounds like what you want, but I don't > know what the implementation does exactly - it was apparently added for > paging in ahead, and maybe it ignores unpopulated anonymous areas, but > it would probably be well in spirit of the flag to make it prepopulate > those. It doesn't seem to do anything for anon mappings atm but I do see a patch from 2008 for that. I guess it never landed.
Attachment:
signature.asc
Description: OpenPGP digital signature