views:

114

answers:

2

As I understand it MEM_RESERVE is actually 'free' memory, ie available to be used by my process, but just hasn't been allocated yet? Or it was previously allocated, but had since been freed?

Specifically, see in my !address output below how I am nearly out of virtual address space (99900 KB free, 2307872 as MEM_PRIVATE. But the states shows that 44.75% of that is actually MEM_RESERVE. Does that mean it is actually free, in my process...but maybe fragmented?

0:000> !address -summary
 --------- PEB a8bd8000 not found ----

-------------------- Usage SUMMARY --------------------------
    TotSize (      KB)   Pct(Tots) Pct(Busy)   Usage
   259af000 (  616124) : 22.29%    23.12%    : RegionUsageIsVAD
    618f000 (   99900) : 03.61%    00.00%    : RegionUsageFree
   13e22000 (  325768) : 11.78%    12.22%    : RegionUsageImage
   42c04000 ( 1093648) : 39.56%    41.04%    : RegionUsageStack
     42d000 (    4276) : 00.15%    00.16%    : RegionUsageTeb
   2625d000 (  625012) : 22.61%    23.45%    : RegionUsageHeap
          0 (       0) : 00.00%    00.00%    : RegionUsagePageHeap
          0 (       0) : 00.00%    00.00%    : RegionUsagePeb
       1000 (       4) : 00.00%    00.00%    : RegionUsageProcessParametrs
       1000 (       4) : 00.00%    00.00%    : RegionUsageEnvironmentBlock
       Tot: a8bf0000 (2764736 KB) Busy: a2a61000 (2664836 KB)

-------------------- Type SUMMARY --------------------------
    TotSize (      KB)   Pct(Tots)  Usage
    618f000 (   99900) : 03.61%   : <free>
   13e22000 (  325768) : 11.78%   : MEM_IMAGE
    1e77000 (   31196) : 01.13%   : MEM_MAPPED
   8cdc8000 ( 2307872) : 83.48%   : MEM_PRIVATE

-------------------- State SUMMARY --------------------------
    TotSize (      KB)   Pct(Tots)  Usage
   57235000 ( 1427668) : 51.64%   : MEM_COMMIT
    618f000 (   99900) : 03.61%   : MEM_FREE
   4b82c000 ( 1237168) : 44.75%   : MEM_RESERVE

Largest free region: Base 7e4a1000 - Size 000ff000 (1020 KB)

FOLLOW UP:

So in terms of my example, this process is reporting 'out of memory', but actually it COULD make allocations, but someone MEM_RESERVED more than they needed at that point, preventing someone else from even being able to allocate?

+2  A: 

MEM_RESERVE is allocated by the process. I.e. the address space is considered in use. However, it has not been committed. To actually use the memory for storage, it must be committed. Mark Russinovich has an excellent post, that describes all the details. From the post

Testlimit’s –r switch has it reserve virtual memory, but not actually commit it. Reserved virtual memory can’t actually store data or code, but applications sometimes use a reservation to create a large block of virtual memory and then commit it as needed to ensure that the committed memory is contiguous in the address space. When a process commits a region of virtual memory, the operating system guarantees that it can maintain all the data the process stores in the memory either in physical memory or on disk. That means that a process can run up against another limit: the commit limit.

Brian Rasmussen
So in terms of my example, this process is reporting 'out of memory', but actually it COULD make allocations, but someone MEM_RESERVED more than they needed at that point, preventing someone else from even being able to allocate?
pj4533
MEM_RESERVED is per process, so the process reserved that memory not someone else (as in another process).
Brian Rasmussen
Sure, but the point being, that this process is reporting that allocations are failing, so the problem is that someone (some subsystem in THIS process) MEM_RESERVED more memory, and its preventing some other subsystem from making allocations?
pj4533
Sorry, I got confused by the "someone" part. Anyway, it is hard to tell. As some part of the code reserved memory I would assume that it will eventually need that memory for something. Without further detail it is hard to pinpoint the source of the problem.
Brian Rasmussen
yeah I think I got it. after loading my DMP file in debug diag, its obvious. I have like >1000 threads all stuck on EndThreadEx. Each one reserves a meg of memory, but only commits 20kb. So I just have to figure out who is making this thread that doesn't want to quit.thanks for the help!
pj4533
Threads reserve stack space but only commit as needed (unless you're on .NET in which case they commit up front). Getting rid of some of the 1000 threads will probably be a good idea :)
Brian Rasmussen
A: 

Have look here. Very well explained

http://blogs.msdn.com/webtopics/archive/2010/04/02/address-summary-explained.aspx

Jas