I'm working with OpenEmbedded and TI's OMAP3530 ARM/DSP combo. TI provides a special kernel module `cmemk.ko` which and a library which interfaces with it and provides functions such as alloc_contig()
My educated guess is that dynamically allocated memory is subject to fragmentation (just like a hard drive) and that this could lead to latency in cases where the CPU is spending a few clock cycles performing the logic to physically address the memory 100MB away to get the next bit of virtual memory. AJ ONeal On Mon, Aug 23, 2010 at 11:49 AM, Dan Burton <[email protected]>wrote: > For way too much information that doesn't quite answer your question, see: > http://en.wikipedia.org/wiki/Malloc#Implementations > > <http://en.wikipedia.org/wiki/Malloc#Implementations>The simple cop-out > answer is this: it depends on the OSs implementation of malloc. Someone > could certainly write an OS that works as you describe. How exactly popular > OSs actually work in this regard, I'm not quite sure. > > On Mon, Aug 23, 2010 at 11:40 AM, AJ ONeal <[email protected]> wrote: > >> Would it be true to say that if I allocate 120MB of memory with `malloc()` >> that the physical memory underneath may actually be a block of 80MB and >> 40MB? >> >> Now with a system with 4GB+ of memory, perhaps that's not very likely... >> but it is possible, correct? >> >> AJ ONeal >> >> -------------------- >> BYU Unix Users Group >> http://uug.byu.edu/ >> >> The opinions expressed in this message are the responsibility of their >> author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. >> ___________________________________________________________________ >> List Info (unsubscribe here): >> http://uug.byu.edu/mailman/listinfo/uug-list >> > > > > -- > Dan Burton > 801-513-1596 > > -------------------- > BYU Unix Users Group > http://uug.byu.edu/ > > The opinions expressed in this message are the responsibility of their > author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. > ___________________________________________________________________ > List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list >
-------------------- BYU Unix Users Group http://uug.byu.edu/ The opinions expressed in this message are the responsibility of their author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. ___________________________________________________________________ List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list
