You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am trying to use extent_hooks to count memory allocations in the program, and I encountered a weird problem. If opt.retain is set to true, the alloc hook is rarely called with *commit==true. But on the other hand, there are all the time calls to decommit and purge.
From docs, it stands that when purge_forced is called with success, memory should be unmapped from the physical address space. If decommit is success (err=false), it should also be decommited from physical address space.
I understand that opt.retain=true is used so that virtual memory address space doesn't want to be fragmented, but from documentation, it seems that either commit hook should be called more often, or alloc hook should be called with *commit==true.
By counting allocations from hooks it seems that memory is in negative, due to frequent calls to decommit and purge.
Here are stats I get from program, by counting calls to my wrapper function for extent hooks:
I am using jemalloc version 5.2.1. My custom hooks are used only as a wrapper around default jemalloc hooks as you can see. purge_forced and decommit are called constantly trying to unmap certain pages, but nothing really gets deallocated by tracking RES size on htop.
To avoid calling lazy purging, I am forcing jemalloc to use MADV_DONTNEED instead of MADV_FREE by setting the following flags to 0: muzzy_decay_ms:0, dirty_decay_ms:0
Also, by setting oversize_threshold to a big number, I want to disable jemalloc for using a custom arena for huge allocations as you can't set a custom hook on that arena if you don't modify the code itself.
From debugging, it seems jemalloc arena_decay_to_limit calls arena_decay_stashed which calls extent_dalloc_wrapper which first tries to decommit but fails and then tries purging memory. I don't understand why that happens. It all starts with the call of free.
My question is, why is purge called with success if nothing happens, and how should I adapt program to correctly count allocations?
The text was updated successfully, but these errors were encountered:
I am trying to use
extent_hooks
to count memory allocations in the program, and I encountered a weird problem. Ifopt.retain
is set totrue
, thealloc
hook is rarely called with*commit==true
. But on the other hand, there are all the time calls todecommit
andpurge
.From docs, it stands that when
purge_forced
is called with success, memory should be unmapped from the physical address space. If decommit is success (err=false), it should also be decommited from physical address space.I understand that
opt.retain=true
is used so that virtual memory address space doesn't want to be fragmented, but from documentation, it seems that either commit hook should be called more often, or alloc hook should be called with*commit==true
.By counting allocations from hooks it seems that memory is in negative, due to frequent calls to decommit and purge.
Here are stats I get from program, by counting calls to my wrapper function for extent hooks:
Here is how I get the hooks and set custom hooks:
Now once these hooks are set, here are definitions of my wrappers around jemalloc hooks:
I am using
jemalloc
version 5.2.1. My custom hooks are used only as a wrapper around default jemalloc hooks as you can see.purge_forced
anddecommit
are called constantly trying to unmap certain pages, but nothing really gets deallocated by tracking RES size onhtop
.To avoid calling lazy purging, I am forcing jemalloc to use MADV_DONTNEED instead of MADV_FREE by setting the following flags to 0:
muzzy_decay_ms
:0,dirty_decay_ms
:0This is how I configure jemalloc:
Also, by setting
oversize_threshold
to a big number, I want to disable jemalloc for using a custom arena for huge allocations as you can't set a custom hook on that arena if you don't modify the code itself.From debugging, it seems jemalloc
arena_decay_to_limit
callsarena_decay_stashed
which callsextent_dalloc_wrapper
which first tries to decommit but fails and then tries purging memory. I don't understand why that happens. It all starts with the call offree
.My question is, why is purge called with success if nothing happens, and how should I adapt program to correctly count allocations?
The text was updated successfully, but these errors were encountered: