Hi,

How good is Linux's memory management (MM) in this version? would it be a good idea to develop a thin, simple and robust layer of memory management in my application on top of Linux MM, since my app allocs and deallocs a bunch (a high number) of pieces of memory of similar size (not exact the same size but close)? Performance is critical in my app.

Thanks!

Linuxer

well the kernel has to and is going to do it on its own anyway no matter what your user space sugestions so i think more code is a waste of resources.
i think linux MM is very good now but it kind of depends on the hardware setup.
if you have something exotic like NUMA setup it's not going to be as good but like i said the kernel has to do it so the only option to improve it is kernel hacking.
i think one of the experimental branches of the kernel is the MM branch if you feel like experimenting. I bet they like feedback as well.

The memory-management code that your application invokes are actually provided by the runtime libraries used by your application, such as glibc. These libraries handle the complexities of malloc() and free(), et al, calling upon the kernel only to obtain additional (large) chunks of memory as-needed. The kernel is not bothered with trifles.

If you have a high-performance memory requirement like this, consider implementing your own layer of code within your appliation. Handle all memory-allocation requirements by calling this layer.

Consider implementing a "free list," one for each chunk-size. When you release a memory block, just fill it with garbage bytes and chain it to the appropriate free-list. The next request for the same-sized block can check to see if the free-list has anything on it. If so, the first block is dequeued, set to binary zeroes, and returned. A LIFO (last-in first-out) strategy is used to increase the probability that the necessary memory-pages will not have been swapped out yet; the address is "recently used."

If you have many memory allocation requests of a similar size, round them up to a convenient larger size. In the long run, a few extra bytes won't matter. Then use the free-list strategy outlined above.

In the free-list strategy, you never check any other list when satisfying memory requests. You don't "clean up" the lists, or get excited about how many entries they might contain.

I find it very helpful to "fill released blocks with garbage," so that if I accidentally refer to it later the problem is very noticeable. (Finding garbage-bytes in a released block is also an indication of the dreaded "double free.") I also find it very helpful to set the newly allocated (or re-used) blocks explicitly to binary zeroes. Adding a few extra (known-zero) bytes to every memory allocation is also a useful idea.

yes in a way what sundialsvcs says makes sense but just keep in mind
*all user space memory programming is virtual only*
it ain't got one single thing to do with actual management of physical memory
which is what i thought you were talking about kernel level MM and performance of your application.

so yes you can manage your programs use of virtual memory you cannot manage your programs use of actual memory from user space.

High-performance applications definitely need to consider the vagaries of a virtual-memory environment. Here are a few ways in which you can do that...

Try to re-use "recently used" things. A memory block that has been recently used probably hasn't been paged-out yet. Hence, the free-lists that I spoke of should use a LIFO (last-in first-out, "pushdown") discipline. The most recently disposed-of element is the one that's popped back off first.

Use hash tables and trees, instead of singly-linked lists, so that you can locate information with a minimum number of memory references. Each memory-reference has the potential of causing a page fault.

Use large "in-memory" buffers instead of disk-files, because your program's memory is, in fact, "a disk file." It's the system paging file, and it's going to be managed as efficiently as it possibly can be by the operating-system kernel itself. Nonetheless, view "memory" as you would a file, considering (as I said before) that each new reference to a "not-nearby" address could result in a page fault.

Don't stare fixedly at the "amount of" memory being used. As long as the working-set size (the number of "recently used" pages) is not excessive, in a system that is actually undergoing some amount of virtual-memory stress, the total size of the memory-allocation is little more than "the current size of that great-big file." Don't abuse or waste the memory resource, but also don't fixate on the particular numbers even when they become large.

This is really nice post sundialsvcs. I have a similar requirement. To be precise, we use free list approach you mentioned earlier with 512 byte chunk size.

However, we do see heavy memory contentions when lots of threads are doing work. what happens is that, when all the threads wake up and try to get memory from the memory layer, it severely contends for lock and sometimes it takes even 100ms to acquire the lock (1% of the total requests).

We do see heavy context switches. Do you have any suggestions on this?