This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: allocating aligned memory efficiently


On Sun, 21 Feb 2010, Nobin Mathew wrote:

This might be helpful

http://freecode4freedom.blogspot.com/2010/01/minor-page-faults-and-dynamic-memory.html

It is, thanks. It makes me wish there was some kind of soft_munmap system call which tells the kernel, "I don't need these pages anymore, but if they haven't been reused by the time I ask for new pages (via a corresponding soft_mmap call), just give me back the old ones -- you don't even have to zero them out!" I don't know how feasible that is, but it seems like it might help avoid such page fault thrashing.


Anyway, I plan to write two versions of my chunk allocation/deallocation code -- one based on posix_memalign/free and the other based on mmap/munmap -- and profile both to see what the time/space tradeoff is in practice for my workloads.

On Sun, Feb 21, 2010 at 8:05 AM, Joel Dice <joel.dice@gmail.com> wrote:
On Sat, 20 Feb 2010, Carlos O'Donell wrote:

On Fri, Feb 19, 2010 at 7:34 PM, Joel Dice <joel.dice@gmail.com> wrote:

Hi all,


I have a problem which involves allocating memory in chunks, each of a
size
which is a multiple of 64K and each aligned to an address divisible by
64K.
?I'd like to make these allocations as memory-efficient as possible,
minimizing fragmentation and heap management overhead, and I'd like to
free
each one back to the OS promptly when it's no longer needed.

Your last requirement is not honoured by glibc, the allocator attempts to maximize performance by reusing already mapped blocks of memory, it does not free them promptly (if ever).

The posix_memalign(3) and free(3) functions seem to have the semantics I
want. ?Is this pair the most efficient option for my problem, or would I
be
better off using mmap(2) or some other mechanism?

If you want it free'd back to the OS promptly then I suggest you use mmap(2) and manage the memory yourself.

That makes sense, thanks.


In order to get the alignment I want, I will ask mmap for 64K more than I
need and then immediately trim the excess using munmap so that the result
starts on an aligned address. ?If there's a better way, I'd be glad to hear
it.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]