> On Jan 18, 2016, at 11:35 PM, RajaKishore Sahu <[email protected]> wrote: > > Hi Luke, > > Thanks for your reply. > > I am trying to port Jemalloc to a embedded environment where we have only 40 > MB of memory for a subsystem. > > While porting I found that in start up it is consuming almost 38 MB of memory > with arena size of 1MB. We spawn around 70 threads in the start up.
So are these threads eating up lots of memory with their stacks? > So we are only 2 MB left for that subsystem. While the system is in run > definitely it will ask for more memory, in that case how we are going to > satisfy the memory needed by Jemalloc? > > Current allocator consumes around 20 - 22 MB of memory and remaining is used > for the system to run. > > Or Jemalloc is not suited for embedded environment? Possibly not. I really don’t know anything about configuring in a small memory environment, sorry. You could try tbbmallloc if you have access to it and can cope with C++. It might have different overheads given its different design. We find it to be slightly slower than jemalloc but a bit better about memory usage. These are on large memory nodes though, not sure about its memory-constrained constrained. I seem to recall reading some papers about concurrent memory allocation for embedded systems as well, but can’t find them off the top of my head. Good luck, Luke > > Thanks > Rajakishore > > > On Tue, Jan 19, 2016 at 9:02 AM, D'Alessandro, Luke K <[email protected]> > wrote: > > > On Jan 17, 2016, at 9:53 PM, RajaKishore Sahu <[email protected]> wrote: > > > > Hi, > > > > I have a follow up question. > > > > We have only 40 MB of memory for our sub system. > > > > I start up Jemalloc is keep asking for new chunks and by the time the > > system becomes ready it almost consumes 38 MB of memory. > > > > How we can tell Jemalloc to uses already allocated memory chuck when we run > > out of our 40 MB of memory? > > I’m not sure this has anything to do with jemalloc. It just allocates chunks > in response to application demand when it can’t satisfy new allocations given > its existing chunks. That being said, I don’t know much about using jemalloc > in constrained environments—we’re using it in 128GB settings. > > Are you suffering from terrible fragmentation? Is this consistent across > different allocations? I supposed it’s easily possible that jemalloc needs a > bunch of memory for its own infrastructure for trees and such. > > Luke > > > > > Thanks > > Rajakishore > > > > On Tue, Oct 13, 2015 at 8:21 AM, RajaKishore Sahu <[email protected]> > > wrote: > > Hi Luke, > > > > Thanks for sharing the details. I will go through the code and come back if > > I need some more help. > > > > Thanks > > Rajakishore Sahu > > > > On Mon, Oct 12, 2015 at 5:09 PM, D'Alessandro, Luke K > > <[email protected]> wrote: > > > > > On Oct 12, 2015, at 1:12 AM, RajaKishore Sahu <[email protected]> wrote: > > > > > > Hi, > > > > > > I am trying to port Jemalloc. We are going to use it for our sub-system > > > not for the whole system. > > > > > > Main system has its own memory manager. While initializing the sub-system > > > (in boot up) we will allocate memory from main system (Ex:- 10 MB) which > > > will be contiguous memory then we want to give the start address and size > > > to Jemalloc to manage it. Please let us know where to provide the start > > > address to jemalloc? > > > > Hi. This dlmalloc-mspace-like interface isn’t really supported by jemalloc, > > which wants to be able to request “chunks” of memory from the system using > > a chunk allocator (typically mmap()). > > > > To do what you want you need to write a chunk provider based on [the chunk > > hooks > > class](http://www.canonware.com/download/jemalloc/jemalloc-latest/doc/jemalloc.html), > > and then install it for all of the threads in your code. Your chunk > > provider will have to give jemalloc chunks from your contiguous region. > > > > We do this in HPX-5 to manage a network-registered global heap. The > > callback chunks are > > [here](https://gitlab.crest.iu.edu/extreme/hpx/blob/develop/libhpx/gas/pgas/jemalloc_global.c) > > and the “heap” is implemented > > (here)[https://gitlab.crest.iu.edu/extreme/hpx/blob/develop/libhpx/gas/pgas/heap.c]. > > This code is slightly complex but it’s basically just using a bitmap to > > allocate chunks from a large contiguous heap, and can serve as an example > > for you. > > > > > Main system will provide thread, Mutex/Semaphore and the memory for this > > > will not be allocated from the sub-system. In this scenario how can we > > > enable thread caching? We do have a rapper to create threads, which means > > > we know which are the the threads created by sub-system. Will it help in > > > enabling the thread caching? > > > > Thread caching will likely be on by default for the threads. In more > > complex code where you might want to manage more than one memory space, you > > may need to explicitly allocate new caches. > > > > Luke > > > > > > > > Any help will greatly appreciated! > > > > > > > > > -- > > > Thanx > > > Rajakishore Sahu > > > Mail:[email protected] > > > _______________________________________________ > > > jemalloc-discuss mailing list > > > [email protected] > > > http://www.canonware.com/mailman/listinfo/jemalloc-discuss > > > > > > > > > > -- > > Thanx > > Rajakishore Sahu > > Mail:[email protected] > > Mobile:-+91 9886719841 > > > > > > > > -- > > Thanx > > Rajakishore Sahu > > Mail:[email protected] > > Mobile:-+91 9886719841 > > > > > -- > Thanx > Rajakishore Sahu > Mail:[email protected] > Mobile:-+91 9886719841 _______________________________________________ jemalloc-discuss mailing list [email protected] http://www.canonware.com/mailman/listinfo/jemalloc-discuss
