about dwAllocationGranularity of SYSTEM_INFO

This is a discussion on about dwAllocationGranularity of SYSTEM_INFO within the Windows Programming forums, part of the Platform Specific Boards category; 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 ...

  1. #1
    Registered User
    Join Date
    May 2006
    Posts
    1,579

    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

  2. #2
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  3. #3
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks CornedBee,

    1.

    Quote Originally Posted by CornedBee View Post
    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 View Post
    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

  4. #4
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    No, the allocation granularity deals with virtual addresses, not physical RAM.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  5. #5
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    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 View Post
    No, the allocation granularity deals with virtual addresses, not physical RAM.

    regards,
    George

  6. #6
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  7. #7
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Moving this, by the way.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  8. #8
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks Mats,


    My question is answered.

    Quote Originally Posted by matsp View Post
    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

Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21