Reason opt.lg_dirty_mult is not writable?

[D'Alessandro, Luke K]

> On Jan 21, 2015, at 4:10 PM, Jason Evans <jasone at canonware.com> wrote:
> 
> 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”?  

Ah, maybe? I didn’t realize that we could mangle those up front, the opt code can be pretty opaque :-) That would be good enough for my purposes. So if my configuration normally generates the symbol as “prefix_je_opt_lg_dirty_mult”, then can I use that fully mangled name?


> 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?

Yes. I didn’t realize that the environment could contain the mangled name.

> 
>> 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.

Ah, okay. I’ll see if the mangled version works.

As a side note, we run into some symbols that aren’t properly mangled to link against two jemalloc instances. At some point (soon) we’ll submit an upstream patch to mangle them.

Luke

> Thanks,
> Jason