Results 1 to 2 of 2
My question is a bit hard to summarise, so I'll just dive into it straight away.
Suppose I malloc() an array of some significant size, say a few hundred pagesizes' ...
- 11-10-2007 #1Just Joined!
- Join Date
- Nov 2007
- Posts
- 1
malloc(), mmap() and virtual memory
My question is a bit hard to summarise, so I'll just dive into it straight away.
Suppose I malloc() an array of some significant size, say a few hundred pagesizes' worth. I don't use the array for now: there is no attempt to clear it, nor store data in nor read data from it yet. It has only been malloc()ed.
Now the glibc-documentation states that ... On some systems using private anonymous mmaps is more efficient than using malloc for large blocks. This is not an issue with the GNU C library, as the included malloc automatically uses mmap where appropriate. ... Does that mean that this array for the moment only uses virtual memory, without being backed by physical memory; and that Linux' memory manager will begin to reserve pages in physical memory (if necessary by relying on swap space) as soon as I begin to use the array (clear it, store values in it, etc.)? Or, in other words, if I monitor virtual and real memory usage of my program, will I see a large jump in virtual memory usage with the malloc(), and then a steadily growing usage of real memory as I begin to fill in the array?
If my understanding of the system is indeed correct, is there a way to influence this process? Suppose, for example, that for some reason (although I cannot think of one right now) I would like to have the system reserve all physical memory necessary to store the array immediately upon the call to malloc(). Is such a thing possible?
The reason I want to know is that until now, I just malloc()ed away, and used what I got in return. But sometimes one wishes to know what exactly goes on within the crevices of the system
. I did locate the eBook 'Inside the Linux VM Manager', but this is far too detailed and complex to answer my quesiton.
- 11-10-2007 #2"In other words" doesn't apply here, because the answers to the two questions are different.in other words
Pretty much, yes. There are a few overhead bytes at (from the userland coder's point of view, not "at" but "just before") the beginning of the malloc()ed memory that help the library know how much memory is being freed when (if) you later do a free() There may also be a little bit of overhead at the end; I'm not sure, my um memory fails me here. Since this is real data, it will appear in main memory immediately.Does that mean that this array for the moment only uses virtual memory, without being backed by physical memory; and that Linux' memory manager will begin to reserve pages in physical memory (if necessary by relying on swap space) as soon as I begin to use the array (clear it, store values in it, etc.)?
Only in a perfect world. After a while, some of this filled-in array may (and in most situations almost certainly will) get swapped out due to memory demands from other processes. When data in real memory gets swapped out, the real memory usage of the first process will of course decrease.if I monitor virtual and real memory usage of my program, will I see a large jump in virtual memory usage with the malloc(), and then a steadily growing usage of real memory as I begin to fill in the array?
Presumably you are willing for the system to swap out memory of other processes to make this possible, if necessary.I would like to have the system reserve all physical memory necessary to store the array immediately upon the call to malloc().
Yes. Do this at the command line:Is such a thing possible?
and all will be revealed.Code:man mlock man munlock man mlockall man munlockall man setrlimit
--
Bill
Old age and treachery will overcome youth and skill.


Reply With Quote