about dwAllocationGranularity of SYSTEM_INFO

Hello everyone,


I read the description of dwAllocationGranularity from,

1. http://msdn2.microsoft.com/en-us/library/ms724958.aspx

2. http://msdn2.microsoft.com/en-us/lib...87(VS.85).aspx

and tested on my system it is 65535.

But from the above description, I do not quite understand what does it mean. Does it mean that when memory manager deals with real memory allocation, it will always allocate 65535 bytes at a time, and divide into small chunks to upper level API (for example, when we new[256], it will allocate 256 bytes from the 65535 allocated raw bytes to application)?

Another question is, what benefit will we get if we know this parameter? For example, how do we allocate memory will utilize the system at most to achieve best performance?


thanks in advance,
George

It means that if you want memory at a specific virtual address, that address has to be a multiple of the granularity. It doesn't have anything to do with the actual allocated size.

I have no idea how you would use this information, other than for checking that your program doesn't make a faulty assumption about fixed addresses it can allocate at.

Thanks CornedBee,

1.

Quote:

---

Originally Posted by CornedBee

It means that if you want memory at a specific virtual address, that address has to be a multiple of the granularity. It doesn't have anything to do with the actual allocated size.

---

I think you mean memory is aligned with the times of dwAllocationGranularity of SYSTEM_INFO, right?

Quote:

---

Originally Posted by CornedBee

I have no idea how you would use this information, other than for checking that your program doesn't make a faulty assumption about fixed addresses it can allocate at.

---

How to check it? I think we could only deal with virtual address, but dwAllocationGranularity should deal with real physical (RAM) address?


regards,
George

No, the allocation granularity deals with virtual addresses, not physical RAM.

Thanks CornedBee,


1. So, it deals with virtual address alignment, right?

2. It deals with virtual page address level, right? What makes me confused is, if we use higher level API, like new to allocate a small portion of memory, surely it is not aligned at address times of dwAllocationGranularity. What do you mean "make a faulty assumption about fixed addresses it can allocate at"? :-)

Quote:

---

Originally Posted by CornedBee

No, the allocation granularity deals with virtual addresses, not physical RAM.

---

regards,
George

First of all, this has nothing do with "new" or "malloc". It has to do with the much lower level "VirtualAlloc" (and friends).

Quote:

---

Originally Posted by MSDN

For more information, see VirtualAlloc.

---

VirtualAlloc allows your process to allocate larger chunks of memory with specific settings. The base-address of these allocations need to be aligned to 64K - this is most likely a fairly arbitrary size, a compromize between 4K which is the smallest possible virtual address, and the fact that each of the allocations need to be "tracked", so if you have lots of small ones, the OS needs a large amount of memory to track the allocations. Fewer, bigger, ones will need less admin memory.

--
Mats

Moving this, by the way.

Thanks Mats,


My question is answered.

Quote:

---

Originally Posted by matsp

First of all, this has nothing do with "new" or "malloc". It has to do with the much lower level "VirtualAlloc" (and friends).

VirtualAlloc allows your process to allocate larger chunks of memory with specific settings. The base-address of these allocations need to be aligned to 64K - this is most likely a fairly arbitrary size, a compromize between 4K which is the smallest possible virtual address, and the fact that each of the allocations need to be "tracked", so if you have lots of small ones, the OS needs a large amount of memory to track the allocations. Fewer, bigger, ones will need less admin memory.

--
Mats

---

regards,
George