<quote name="AJ ONeal" date="Mon, 23 Aug 2010 at 12:15 -0600"> > > Exactly - it makes no difference. The memory subsystem will be taking > > chunks from ram and pulling them up through the cache heirarchy anyway - > > nothing uses the ram for operations, and there would be no performance > > penalty for having fragmented ram. > > > > >From what I learned back in EE/CS124, I believe that there is no latency > between addresses within a certain range, but there is latency between > addresses outside of that range.
In answer to the original question, malloc() always gives a contiguous chunk of *virtual* memory. That is, as far as the application sees it the addresses are contiguous, otherwise how is the application going to know where its chunk of memory is chunked? As has been pointed out, *all* memory references go through the VM... well, that's not 100% accurate. As has also been mentioned, caching is a factor as well, but most systems now days cache on the virtual address, so if you access address X, that page gets pulled in from the VM, and is cached, you access X + 0x04, and that's in the same page, it's right there in the cache. Any preloading or other caching strategies that try to pull in "close" addresses at once will pull in addresses that are "close" in virtual address. So it really doesn't matter when actual physical memory is fragmented - there is no performance hit. The only thing fragmentation does is break up the address space and possibly make allocation requests fail because there is no contiguous _address_ block to fit the request. This is, of necessity, on a virtual memory system only on a per application basis. One application can have a badly fragmented memory space and fail on allocation requests, but it will not effect the ability of a seperate program to do the same. However, when you are actually depleted of pages, very bad things happen. ;) Von Fugal -- Government is a disease that masquerades as its own cure -- Robert Lefevre
signature.asc
Description: Digital signature
-------------------- 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
