> On Jan 21, 2015, at 4:10 PM, Jason Evans <[email protected]> wrote: > > On Jan 21, 2015, at 11:17 AM, D'Alessandro, Luke K <[email protected]> > 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 _______________________________________________ jemalloc-discuss mailing list [email protected] http://www.canonware.com/mailman/listinfo/jemalloc-discuss
