search for: tcmalloc

...m not very happy with my use of... #if defined(__GLIBC__) This will work in the common case where glibc is being used with its standard allocator. However it will completely fail in the case where LLVM is being used as a library and a developer chooses to use a different allocator. For example if tcmalloc [2] is used then the calculation is wrong[3] because mallinfo.uordblks includes mmap()'ed memory and so we would count mmap()'ed memory twice! Thoughts? [1] http://llvm.org/bugs/show_bug.cgi?id=16847 [2] http://goog-perftools.sourceforge.net/doc/tcmalloc.html [3] https://github.com/klee/k...

On 12 August 2017 at 15:10, luke-tierney at uiowa.edu wrote: | As the Python posts poitns out, it is possible to use alternate malloc | implementations, either rebuilding R to use them or using LD_PRELOAD. | On Ubuntu for example, you can have R use jemalloc with | | sudo apt-get install libjemalloc1 | env LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.1 R | | This does not seem to hold

...e are some slides from the > meeting here[1]: > http://indico.cern.ch/getFile.py/access?contribId=8&sessionId=1&resId=1&materialId=slides&confId=106641 On Wed, Feb 9, 2011 at 12:41 PM, Chris Jones <christopher.rob.jones at cern.ch> wrote: > > I would say a bug in tcmalloc, not SL or RHEL. See for instance > > <http://code.google.com/p/google-perftools/issues/detail?id=305> > > The fix is to move to google perftools 1.7 </quote> Because of a problem with not running the current BIND release a couple of weeks ago, I would like to ask: a) is...

Thanks for the reply. On 28 April 2014 20:01, Reid Kleckner <rnk at google.com> wrote: > The problem with tcmalloc seems like a real problem. I can't think of any > good workarounds. My best worst idea is to try to figure out if malloc is > coming from libc with dlsym and dlopen, and then use that to decide whether > we add these two numbers together. I'm not sure we can always assume libc i...

...> IR to allow for explicitly selecting which model to use for > thread-local storage of a variable. > > The motivation is to allow Clang to support the "tls_model" variable > attribute [1], as requested in PR9788. This enables better performance for some code. For example, TCMalloc [3] would like to use the initial-exec model, because it's faster. > The idea would be to extend the IR to allow an optional TLS-model > argument to the thread_local attribute, like this: > >  @x = thread_local(initialexec) global i32 42 > > Just as it is illegal to specify t...

Hi all, I would like to hear your thoughts on adding support for extending the IR to allow for explicitly selecting which model to use for thread-local storage of a variable. The motivation is to allow Clang to support the "tls_model" variable attribute [1], as requested in PR9788. The idea would be to extend the IR to allow an optional TLS-model argument to the thread_local

Two ideas, one more controversial than the other. First: auto-killing bloated workers.?My current app has some memory leakage that wasn''t really visible on our older passenger setup, since the auto-scaling meant that bloated workers got killed periodically. In a perfect world, we''d find and patch all of the leaks, but in the meantime (and as a safety net) I''d like to get

...to jemalloc, we could design a test bench and > compare what the impact is. > > Similarly, if someone cared, I could (presumably) alter the default R build > for Debian and Ubunto to also switch to jemalloc. Depending on how this turns out, Fedora, RHEL, Centos also have jemalloc and tcmalloc. Meaning, if its good on those two, its good on Linux in general. Basically, jemalloc is faster for many work loads but its harder to spot problems. Glibc is better at spotting memory bugs but not as fast. -Steve > Anybody feel like doing some empirics? > > Dirk

...- kvm-cirrus-fix-oob-access-issue-CVE-2017-2615.patch [bz#1418234] - Resolves: bz#1418234 (CVE-2017-2615 qemu-kvm-rhev: Qemu: display: cirrus: oob access while doing bitblt copy backward mode [rhel-7.3.z]) - Resolves: bz#1420456 ([ppc64le]reset vm when do migration, HMP in src host promp "tcmalloc: large alloc 1073872896 bytes...") * Wed Feb 08 2017 Miroslav Rezanina <mrezanin at redhat.com> - rhev-2.6.0-28.el7_3.4 - kvm-Disable-usbredir-and-libcacard-for-unsupported-archi.patch [bz#1420428] - Resolves: bz#1420428 (Remove dependencies required by spice on ppc64le) In order to...

On Wed, 18 Feb 2015, Nathan Kurz wrote: > On Wed, Feb 18, 2015 at 7:19 AM, Radford Neal <radford at cs.toronto.edu> wrote: >>> ... with assignments inside of loops like this: >>> >>> reweight = function(iter, w, Q) { >>> for (i in 1:iter) { >>> wT = w * Q >>> } >>> } >>> ... before the RHS is executed, the

Thanks for the suggestion James, it reduces the commit by about ~900 MB (14,9 GB -> 14 GB). Unfortunately it does not solve the performance problem. The heap is global to the application and thread-safe, so every malloc/free locks it, which evidently doesn’t scale. We could manually create thread-local heaps, but I didn’t want to go there. Ultimately allocated blocks need to share ownership

Hi This array is defined in compiler-rt: InstrProfilingValue.c but I can’t find where it is used? And the comment on it does not say much about why we need it either. Can someone explain why we need this and where it is used? /* A shared static pool in addition to the vnodes statically * allocated by the compiler. */ COMPILER_RT_VISIBILITY ValueProfNode

...ed list and the underlying allocator is now a template parameter. [r206147](http://llvm-reviews.chandlerc.com/rL206147), [r206149](http://llvm-reviews.chandlerc.com/rL206149). The allocator can now also pass the size to the deallocation function, which improves performance with some libraries (e.g. tcmalloc). [r206265](http://llvm-reviews.chandlerc.com/rL20265). * Support for building persistent strongly connected components has been added to the LazyCallGraph. There are detailed comments on the reasoning of this approach and some details on implementation in the commit message. [r206581](http://llvm...

>> In the case of user-defined allocation functions, the definitions for those functions are available >Are they? probably not unless you're in an LTO build. Yes, I'm assuming an LTO build. >Printf() is a very nasty one because it can actually affect a lot of state. The %n modifier can cause an argument to be written to. hence it would have HasInaccessibleState and ArgMemOnly

Strange because in my all my experiments calling malloc.trim always helped - memory reported by top decreased to the level it supposed to be. Do you have in mind case when calling malloc.trim won't do anything? Also shouldn't MALLOC_TRIM_THRESHOLD_ env variable has impact on malloc.trim calls? At the moment seems any value is ignored... 12 ???. 2017 ?. 6:09 ?? ???????????? "Simon

...t, only to discover after carefully tracing through all the values that they were essentially identical but just structured differently (at least between asan and hwasan). This is somewhat philosophical, but to me it seems better to refactor when possible. > > One question about granularity: tcmalloc's allocation granularity is 8, so > by using 64- or 32- byte granules you lose some of the precision. > It depends what you mean by precision. For a single allocation, I end up accumulating the access counts across all corresponding shadows (i.e. if >64 bytes). Although I also added i...

...: no one asked for it previously. And as we like to say > in > > the open-source community: "patches are welcome." > > > > Maksim > > > > P.S. We have updated https://github.com/facebookincubator/BOLT with > instructions on running BOLT with jemalloc or tcmalloc. > > > > On 10/18/19, 11:21 AM, "Sriraman Tallam" <tmsriram at google.com> wrote: > > > > Hello Maksim, > > > > On Fri, Oct 18, 2019 at 10:57 AM Maksim Panchenko <maks at fb.com> wrote: > > Cool. The new numbers look good. If you run B...

Hello Maksim, On Fri, Oct 18, 2019 at 10:57 AM Maksim Panchenko <maks at fb.com> wrote: > Cool. The new numbers look good. If you run BOLT with jemalloc library > > preloaded, you will likely get a runtime closer to 1 minute. We’ve noticed > that > > compared to the default malloc, it improves the multithreaded > > performance and brings down memory usage

Hi all, I've included an RFC for a heap profiler design I've been working on in conjunction with David Li. Please send any questions or feedback. For sanitizer folks, one area of feedback is on refactoring some of the *ASAN shadow setup code (see the Shadow Memory section). Thanks, Teresa RFC: Sanitizer-based Heap Profiler Summary This document provides an overview of an LLVM