question

[gjaegy]

Hi,

sorry to bother you again :) I have two small (stupid?) questions:

• in the case objects are allocated from one thread and always destroyed in another, how does this work ? I assume that's the role of the central cache, and therefore this should cause any problem, is that correct?

• my second question is related to CHUNK_SIZE & MAX_BATCH_SIZE & MAX_BLOCK_SIZE macros. I have increased the CHUNK_SIZE value to 256 KB, in order to cover some frequent allocations occuring in our code which are a little bit greater than 64 KB. Would you recommend to also adjust the other macros, or is it better to leave them as they are ?

Thanks a lot !!

[jlaumon]

I don't know how everything works in the allocator (yet :)), so take my answer with a pinch of salt.

When you free memory, ltalloc doesn't really care where it was allocated. It just puts it in the current thread's free list. When this list is large enough, it moves it back to the central cache.

It makes it really fast, but it also means there is absolutely no debug checks to ensure the pointer wasn't invalid or deleted twice.

For you other question: we also changed the CHUNK_SIZE in our code, it's 4MB for us. We haven't touched the other 2 macros however. I don't have any advice about that, like you, we changed CHUNK_SIZE to cover some frequent allocations we had, but we haven't investigated much yet.

[gjaegy]

Bonjour Jérémy :)

Thanks a lot for your input. This is also the way I understand the allocator works, by maintaining a thread-local list of free blocks, and moving them to the central cache when the list is big enough. Thanks for the confirmation.

The intersting point in your message is that "huge" value you use as chunk size. I assume it works like a charm or you would have set it back to some smaller size, is that right ? Any consequence in the amount of "reserved" memory using such a big chunk size ?

Thanks Greg

[jlaumon]

One consequence is that big allocations which used to go back to the system (with VMFREE) are now kept inside ltalloc free lists until we call ltsqueeze. But it wasn't a problem for us.

I don't exactly remember why we use a value so big (it was a couple of years ago), but it's probably because VMALLOC/VMFREE was especially slow on the platform we were targeting. So I don't necessarily recommand doing the same without profiling first.

[r-lyeh]

hey guys. I also think that you should profile as first step, then tweak everything and see what happens as YMMV :) Personally, I would only tweak CHUNK_SIZE