> That's comparable to Android's pinning / unpinning API for ashmem and I > think it makes sense if it's faster. It's different than the MADV_FREE > API though, because the new allocations that are handed out won't have > the usual lazy commit which MADV_FREE provides. Pages in an allocation > that's handed out can still be dropped until they are actually written > to. It's considered active by jemalloc either way, but only a subset of > the active pages are actually committed. There's probably a use case for > both of these systems. Also, consider that MADV_FREE would allow jemalloc to be extremely aggressive with purging when it actually has to do it. It can start with the largest span of memory and it can mark more than strictly necessary to drop below the ratio as there's no cost to using the memory again (not even a system call). Since the main cost is using the system call at all, there's going to be pressure to mark the largest possible spans in one go. It will mean concentration on memory compaction will improve performance. I think that's the right direction for the kernel to be guiding userspace. It will play better with THP than the allocator trying to be very precise with purging based on aging.
Attachment:
signature.asc
Description: OpenPGP digital signature
