allocating aligned memory efficiently

[Joel Dice]

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.
>