3 ms·
Hi, author here. I'm not sure if I follow your argument. This article doesn't touch on allocators at all (ie. SLUB vs SLAB). It focuses solely on the cost of fr
by bitcharmer 6y ago
Hi, author here. I'm not sure if I follow your argument. This article doesn't touch on allocators at all (ie. SLUB vs SLAB). It focuses solely on the cost of freeing memory which TLB-shootdowns are a notable part of.
I even mention it at the beginning:
> Regardless of the method by which your program acquired memory there are side effects of freeing/reclaiming it.
This post focuses on the impact of so called TLB-shootdowns.
Hope this helps.
- joe_the_user 6y agoAs I understand things, allocating and freeing memory pretty much forms a single system. Especially, if I have a system where I "manually" allocate 10 meg for my use, never free it but use an internal method to mark the memory free or used, I will still have issues with caching and virtual memory based on my use of the memory. IE, reusing memory effectively creating a "roll your own" free and allocate functions. And in general, how contiguously you allocate memory plays a big part in whether freed memory can be easily discarded from the cache. If you get the heap to be exactly like a stack, then the cache shouldn't have problems. But I'll admit I'm not an expert and I could be missing something.
- rocqua 6y agoThis article isn't so much about free-ing, but about unmapping memory. It could well be that you have an allocator that decides not to un-map free-ed memory so that it can quickly be re-used later. That said, as per https://linux.die.net/man/3/malloc https://linux.die.net/man/3/malloc (and the article) the default implementation of free will (in some cases) unmap memory. It is this un-mapping of memory that causes other threads to be affected. Because those threads should get a seg-fault after the unmapping if they try to access that memory.