> In the common case it will be passed many pages by the allocator. There > will still be a layer of purging logic on top of MADV_FREE but it can be > much thinner than the current workarounds for MADV_DONTNEED. So the > allocator would still be coalescing dirty ranges and only purging when > the ratio of dirty:clean pages rises above some threshold. It would be > able to weight the largest ranges for purging first rather than logic > based on stuff like aging as is used for MADV_DONTNEED. I would expect that jemalloc would just start putting the dirty ranges into the usual pair of red-black trees (with coalescing) and then doing purging starting from the largest spans to get back down below whatever dirty:clean ratio it's trying to keep. Right now, it has all lots of other logic to deal with this since each MADV_DONTNEED call results in lots of zeroing and then page faults.
Attachment:
signature.asc
Description: OpenPGP digital signature