Reason opt.lg_dirty_mult is not writable?

[Jason Evans]

On Jan 21, 2015, at 11:17 AM, D'Alessandro, Luke K <ldalessa at indiana.edu> wrote:
> I have an application where we use jemalloc to manage network-registered memory, and we have to make sure that it doesn’t madvise() chunks to the OS or we end up with rDMA failures.
> 
> I can disable madvise() globally with the opt.lg_dirty_mult option using the environment, but that isn’t ideal since there’s no reason that the normal allocator (a separate instance of jemalloc in our case). I have been declaring an extern version of the jemalloc opt variable (prefix_je_opt_lg_dirty_mult in our case), but this means I have to link to the .a directly, rather than linking to the dynamic library or the static library through -ljemalloc_suffix.
> 
> At the same time, this appears to actually work fine.

Can you instead set malloc_conf (with appropriate mangling) to "lg_dirty_mult:-1"?  That's the intended mechanism for setting these options at compile time, though linker subtleties have been known to keep it from working.  Also, if you have two versions of jemalloc linked into your application, doesn't name mangling help you avoid setting lg_dirty_mult for the other copy?

> Until per-chunk-allocator control comes online for this, would it be reasonable to make this option R/W in jemalloc? Is there some corner case that I’m missing that would make this not work?

The historical reason that lg_dirty_mult is read-only is that gracefully transitioning between any two legal values adds complexity, and the primary use cases don't require this functionality.  I just added a note to https://github.com/jemalloc/jemalloc/issues/93 to make this more flexible though, since the internals will have to support the functionality anyway.

Thanks,
Jason