Reason opt.lg_dirty_mult is not writable?
D'Alessandro, Luke K
ldalessa at indiana.edu
Wed Jan 21 13:38:04 PST 2015
> On Jan 21, 2015, at 4:32 PM, Jason Evans <jasone at canonware.com> wrote:
> On Jan 21, 2015, at 1:25 PM, D'Alessandro, Luke K <ldalessa at indiana.edu> wrote:
>>> On Jan 21, 2015, at 4:10 PM, Jason Evans <jasone at canonware.com> wrote:
>>> 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?
> You can use PREFIX_MALLOC_CONF=lg_dirty_mult:-1 in the environment, or you can use prefix_malloc_conf = "lg_dirty_mult:-1" in C code. There should be a distinct *MALLOC_CONF and *malloc_conf for each version of jemalloc you link into your application.
>> 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.
> I just integrated a patch for this today (https://github.com/jemalloc/jemalloc/pull/185).
Great. Internal communication latency, I didn’t realize that went in already.
More information about the jemalloc-discuss