Comparing Memory Allocation Methods

The following is a brief comparison of the various memory allocation methods:

Although the GlobalAlloc, LocalAlloc, and HeapAlloc functions ultimately allocate memory from the same heap, each provides a slightly different set of functionality. For example, HeapAlloc can be instructed to raise an exception if memory could not be allocated, a capability not available with LocalAlloc. LocalAlloc supports allocation of handles which permit the underlying memory to be moved by a reallocation without changing the handle value, a capability not available with HeapAlloc.

Starting with 32-bit Windows, GlobalAlloc and LocalAlloc are implemented as wrapper functions that call HeapAlloc using a handle to the process’s default heap. Therefore, GlobalAlloc and LocalAlloc have greater overhead than HeapAlloc.

Because the different heap allocators provide distinctive functionality by using different mechanisms, you must free memory with the correct function. For example, memory allocated with HeapAlloc must be freed with HeapFree and not LocalFree or GlobalFree. Memory allocated with GlobalAlloc or LocalAlloc must be queried, validated, and released with the corresponding global or local function.

The VirtualAlloc function allows you to specify additional options for memory allocation. However, its allocations use a page granularity, so using VirtualAlloc can result in higher memory usage.

The malloc function has the disadvantage of being run-time dependent. The new operator has the disadvantage of being compiler dependent and language dependent.

The CoTaskMemAlloc function has the advantage of working well in either C, C++, or Visual Basic. It is also the only way to share memory in a COM-based application, since MIDL uses CoTaskMemAlloc and CoTaskMemFree to marshal memory.

AllocateUserPhysicalPages function (memoryapi.h)

Allocates physical memory pages to be mapped and unmapped within any Address Windowing Extensions (AWE) region of a specified process.

64-bit Windows on Itanium-based systems:В В Due to the difference in page sizes, AllocateUserPhysicalPages is not supported for 32-bit applications.

Syntax

Parameters

A handle to a process.

The function allocates memory that can later be mapped within the virtual address space of this process. The handle must have the PROCESS_VM_OPERATION access right. For more information, see Process Security and Access Rights.

The size of the physical memory to allocate, in pages.

To determine the page size of the computer, use the GetSystemInfo function. On output, this parameter receives the number of pages that are actually allocated, which might be less than the number requested.

A pointer to an array to store the page frame numbers of the allocated memory.

The size of the array that is allocated should be at least the NumberOfPages times the size of the ULONG_PTR data type.

Do not attempt to modify this buffer. It contains operating system data, and corruption could be catastrophic. The information in the buffer is not useful to an application.

Return value

If the function succeeds, the return value is TRUE.

Fewer pages than requested can be allocated. The caller must check the value of the NumberOfPages parameter on return to see how many pages are allocated. All allocated page frame numbers are sequentially placed in the memory pointed to by the UserPfnArray parameter.

If the function fails, the return value is FALSE, and no frames are allocated. To get extended error information, call GetLastError.

Remarks

The AllocateUserPhysicalPages function is used to allocate physical memory that can later be mapped within the virtual address space of the process. The SeLockMemoryPrivilege privilege must be enabled in the caller’s token or the function will fail with ERROR_PRIVILEGE_NOT_HELD. For more information, see Privilege Constants.

Memory allocated by this function must be physically present in the system. After the memory is allocated, it is locked down and unavailable to the rest of the virtual memory management system.

Physical pages cannot be simultaneously mapped at more than one virtual address.

Physical pages can reside at any physical address. You should make no assumptions about the contiguity of the physical pages.

To compile an application that uses this function, define the _WIN32_WINNT macro as 0x0500 or later. For more information, see Using the Windows Headers.

MmAllocateContiguousMemory function (wdm.h)

The MmAllocateContiguousMemory routine allocates a range of contiguous, nonpaged physical memory and maps it to the system address space.

Syntax

Parameters

[in] The size, in bytes, of the block of contiguous memory to allocate. For more information, see Remarks.

[in] The highest valid physical address the caller can use. For example, if a device can address only locations in the first 16 megabytes of the processor’s physical memory address range, the driver for this device should set HighestAcceptableAddress to 0x0000000000FFFFFF. If you do not have specific requirements for memory allocation, set to MAXULONG64.

Return value

MmAllocateContiguousMemory returns the base virtual address for the allocated memory. If the request cannot be satisfied, the routine returns NULL.

Remarks

MmAllocateContiguousMemory allocates a block of nonpaged memory that is contiguous in physical address space. The routine maps this block to a contiguous block of virtual memory in the system address space and returns the virtual address of the base of this block. The routine aligns the starting address of a contiguous memory allocation to a memory page boundary.

Drivers must not access memory beyond the requested allocation size. For example, developers should not assume that their drivers can safely use memory between the end of their requested allocation and the next page boundary.

Because contiguous physical memory is usually in short supply, it should be used sparingly and only when necessary. A driver that must use contiguous memory should allocate this memory during driver initialization because physical memory is likely to become fragmented over time as the operating system allocates and frees memory. Typically, a driver calls MmAllocateContiguousMemory from its DriverEntry routine to allocate an internal buffer for long-term use, and frees the buffer just before the driver is unloaded.

Memory allocated by MmAllocateContiguousMemory must be freed when the memory is no longer needed. Call the MmFreeContiguousMemory routine to free memory that is allocated by MmAllocateContiguousMemory.

Memory that MmAllocateContiguousMemory allocates is uninitialized. A kernel-mode driver must first set this memory to zero if it is going to make it visible to user-mode software (to avoid leaking potentially privileged contents).

Physical Memory Allocation in Kernel

I am writting a Kernel Module that is going to trigger and external PCIe device to read a block of data from my internel memory. To do this I need to send the PCIe device a pointer to the physical memory address of the data that I would like to send. Ultimately this data is going to be written from Userspace to the kernel with the write() function (userspace) and copy_from_user() (kernel space). As I understand it, the address that my kernel module will see is still a virtual memory address. I need a way to get the physical address of it so that the PCIe device can find it.

1) Can I just use mmap() from userspace and place my data in a known location in DDR memory, instead of using copy_from_user() ? I do not want to accidently overwrite another processes data in memory though.

2) My kernel module reserves PCIe data space at initialization using ioremap_nocache() , can I do the same from my kernel module or is it a bad idea to treat this memory as io memory? If I can, what would happen if the memory that I try to reserve is already in use? I do not want to hard code a static memory location and then find out that it is in use.

Thanks in advance for you help.

1 Answer 1

You don’t choose a memory location and put your data there. Instead, you ask the kernel to tell you the location of your data in physical memory, and tell the board to read that location. Each page of memory (4KB) will be at a different physical location, so if you are sending more data than that, your device likely supports «scatter gather» DMA, so it can read a sequence of pages at different locations in memory.

The API is this: dma_map_page() to return a value of type dma_addr_t , which you can give to the board. Then dma_unmap_page() when the transfer is finished. If you’re doing scatter-gather, you’ll put that value instead in the list of descriptors that you feed to the board. Again if scatter-gather is supported, dma_map_sg() and friends will help with this mapping of a large buffer into a set of pages. It’s still your responsibility to set up the page descriptors in the format expected by your device.

This is all very well written up in Linux Device Drivers (Chapter 15), which is required reading. http://lwn.net/images/pdf/LDD3/ch15.pdf. Some of the APIs have changed from when the book was written, but the concepts remain the same.

Finally, mmap() : Sure, you can allocate a kernel buffer, mmap() it out to user space and fill it there, then dma_map that buffer for transmission to the device. This is in fact probably the cleanest way to avoid copy_from_user() .

Win32_PhysicalMemory class

The Win32_PhysicalMemory WMI class represents a physical memory device located on a computer system and available to the operating system.

The following syntax is simplified from Managed Object Format (MOF) code and includes all of the inherited properties. Properties are listed in alphabetic order, not MOF order.

Syntax

Members

The Win32_PhysicalMemory class has these types of members:

Properties

The Win32_PhysicalMemory class has these properties.

Attributes

Data type: uint32

Access type: Read-only

SMBIOS — Type 17 — Attributes. Represents the RANK.

This value comes from the Attributes member of the Memory Device structure in the SMBIOS information.

Windows ServerВ 2012В R2, WindowsВ 8.1, Windows ServerВ 2012, WindowsВ 8, Windows ServerВ 2008В R2, WindowsВ 7, Windows ServerВ 2008 and WindowsВ Vista: This property is not supported before Windows ServerВ 2016 and WindowsВ 10.

BankLabel

Data type: string

Access type: Read-only

Physically labeled bank where the memory is located.

Examples: «Bank 0», «Bank A»

This value comes from the Bank Locator member of the Memory Device structure in the SMBIOS information.

Capacity

Data type: uint64

Access type: Read-only

Total capacity of the physical memory—in bytes.

This value comes from the Memory Device structure in the SMBIOS version information. For SMBIOS versions 2.1 thru 2.6 the value comes from the Size member. For SMBIOS version 2.7+ the value comes from the Extended Size member.

For more information about using uint64 values in scripts, see Scripting in WMI.

Caption

Data type: string

Access type: Read-only

Short description of the object—a one-line string.

ConfiguredClockSpeed

Data type: uint32

Access type: Read-only

Qualifiers: MappingStrings («SMBIOS|Type 17|Configured Memory Clock Speed»)

The configured clock speed of the memory device, in megahertz (MHz), or 0, if the speed is unknown.

This value comes from the Configured Memory Clock Speed member of the Memory Device structure in the SMBIOS information.

Windows ServerВ 2012В R2, WindowsВ 8.1, Windows ServerВ 2012, WindowsВ 8, Windows ServerВ 2008В R2, WindowsВ 7, Windows ServerВ 2008 and WindowsВ Vista: This property is not supported before Windows ServerВ 2016 and WindowsВ 10.

ConfiguredVoltage

Data type: uint32

Access type: Read-only

Qualifiers: MappingStrings («SMBIOS|Type 17|Configured voltage»)

Configured voltage for this device, in millivolts, or 0, if the voltage is unknown.

This value comes from the Configured voltage member of the Memory Device structure in the SMBIOS information.

Windows ServerВ 2012В R2, WindowsВ 8.1, Windows ServerВ 2012, WindowsВ 8, Windows ServerВ 2008В R2, WindowsВ 7, Windows ServerВ 2008 and WindowsВ Vista: This property is not supported before Windows ServerВ 2016 and WindowsВ 10.

CreationClassName

Data type: string

Access type: Read-only

Name of the first concrete class that appears in the inheritance chain used in the creation of an instance. When used with the other key properties of the class, the property allows all instances of this class and its subclasses to be identified uniquely.

DataWidth

Data type: uint16

Access type: Read-only

Data width of the physical memory—in bits. A data width of 0 (zero) and a total width of 8 (eight) indicates that the memory is used solely to provide error correction bits.

This value comes from the Data Width member of the Memory Device structure in the SMBIOS information.

Description

Data type: string

Access type: Read-only

Description of an object.

DeviceLocator

Data type: string

Access type: Read-only

Label of the socket or circuit board that holds the memory.

This value comes from the Device Locator member of the Memory Device structure in the SMBIOS information.

FormFactor

Data type: uint16

Access type: Read-only

Implementation form factor for the chip.

This value comes from the Form Factor member of the Memory Device structure in the SMBIOS information.

This property is inherited from CIM_Chip.

HotSwappable

Data type: boolean

Access type: Read-only

If TRUE, this physical media component can be replaced with a physically different but equivalent one while the containing package has the power applied. For example, a fan component may be designed to be hot-swapped. All components that can be hot-swapped are inherently removable and replaceable.

InstallDate

Data type: datetime

Access type: Read-only

Date and time the object is installed. This property does not need a value to indicate that the object is installed.

InterleaveDataDepth

Data type: uint16

Access type: Read-only

Qualifiers: MappingStrings («SMBIOS|Type 20|Interleaved Data Depth»)

Unsigned 16-bit integer maximum number of consecutive rows of data that are accessed in a single interleaved transfer from the memory device. If the value is 0 (zero), the memory is not interleaved.

InterleavePosition

Data type: uint32

Access type: Read-only

Qualifiers: MappingStrings («MIF.DMTF|Memory Device Mapped Addresses|001.7»)

Position of the physical memory in an interleave. For example, in a 2:1 interleave, a value of «1» indicates that the memory is in the «even» position.

Manufacturer

Data type: string

Access type: Read-only

Name of the organization responsible for producing the physical element.

This value comes from the Manufacturer member of the Memory Device structure in the SMBIOS information.

MaxVoltage

Data type: uint32

Access type: Read-only

The maximum operating voltage for this device, in millivolts, or 0, if the voltage is unknown.

This value comes from the Maximum voltage member of the Memory Device structure in the SMBIOS information.

Windows ServerВ 2012В R2, WindowsВ 8.1, Windows ServerВ 2012, WindowsВ 8, Windows ServerВ 2008В R2, WindowsВ 7, Windows ServerВ 2008 and WindowsВ Vista: This property is not supported before Windows ServerВ 2016 and WindowsВ 10.

MemoryType

Data type: uint16

Access type: Read-only

Type of physical memory. This is a CIM value that is mapped to the SMBIOS value. The SMBIOSMemoryType property contains the raw SMBIOS memory type.

This value comes from the Memory Type member of the Memory Device structure in the SMBIOS information.

Unknown (0)

Other (1)

DRAM (2)

Synchronous DRAM (3)

Cache DRAM (4)

EDO (5)

EDRAM (6)

VRAM (7)

SRAM (8)

RAM (9)

ROM (10)

Flash (11)

EEPROM (12)

FEPROM (13)

EPROM (14)

CDRAM (15)

3DRAM (16)

SDRAM (17)

SGRAM (18)

RDRAM (19)

DDR (20)

DDR2 (21)

DDR2—May not be available.

DDR2 FB-DIMM (22)

DDR2—FB-DIMM,May not be available.

DDR3—May not be available.

DDR4 (26)

MinVoltage

Data type: uint32

Access type: Read-only

The minimum operating voltage for this device, in millivolts, or 0, if the voltage is unknown.

This value comes from the Minimum voltage member of the Memory Device structure in the SMBIOS information.

Windows ServerВ 2012В R2, WindowsВ 8.1, Windows ServerВ 2012, WindowsВ 8, Windows ServerВ 2008В R2, WindowsВ 7, Windows ServerВ 2008 and WindowsВ Vista: This property is not supported before Windows ServerВ 2016 and WindowsВ 10.

Model

Data type: string

Access type: Read-only

Name for the physical element.

Name

Data type: string

Access type: Read-only

Label for the object. When subclassed, the property can be overridden to be a key property.

OtherIdentifyingInfo

Data type: string

Access type: Read-only

Additional data, beyond asset tag information, that can be used to identify a physical element. One example is bar code data associated with an element that also has an asset tag. If only bar code data is available and unique or able to be used as an element key, this property is be NULL and the bar code data is used as the class key in the tag property.

PartNumber

Data type: string

Access type: Read-only

Part number assigned by the organization responsible for producing or manufacturing the physical element.

This value comes from the Part Number member of the Memory Device structure in the SMBIOS information.

PositionInRow

Data type: uint32

Access type: Read-only

Qualifiers: MappingStrings («MIF.DMTF|Memory Device Mapped Addresses|001.6»)

Position of the physical memory in a row. For example, if it takes two 8-bit memory devices to form a 16-bit row, then a value of 2 (two) means that this memory is the second device—0 (zero) is an invalid value for this property.

PoweredOn

Data type: boolean

Access type: Read-only

If TRUE, the physical element is powered on.

Removable

Data type: boolean

Access type: Read-only

If TRUE, a physical component is removable (if it is designed to be taken in and out of the physical container in which it is normally found, without impairing the function of the overall packaging). A component can still be removable if power must be «off» to perform the removal. If power can be «on» and the component removed, then the element is removable and can be hot-swapped. For example, an upgradable processor chip is removable.

Replaceable

Data type: boolean

Access type: Read-only

If TRUE, this physical media component can be replaced with a physically different one. For example, some computer systems allow the main processor chip to be upgraded to one of a higher clock rating. In this case, the processor is said to be replaceable. All removable components are inherently replaceable.

SerialNumber

Data type: string

Access type: Read-only

Manufacturer-allocated number to identify the physical element.

This value comes from the Serial Number member of the Memory Device structure in the SMBIOS information.

SKU

Data type: string

Access type: Read-only

Stock keeping unit number for the physical element.

SMBIOSMemoryType

Data type: uint32

Access type: Read-only

The raw SMBIOS memory type. The value of the MemoryType property is a CIM value that is mapped to the SMBIOS value.

Windows ServerВ 2012В R2, WindowsВ 8.1, Windows ServerВ 2012, WindowsВ 8, Windows ServerВ 2008В R2, WindowsВ 7, Windows ServerВ 2008 and WindowsВ Vista: This property is not supported before Windows ServerВ 2016 and WindowsВ 10.

Speed

Data type: uint32

Access type: Read-only

Speed of the physical memory—in nanoseconds.

This value comes from the Speed member of the Memory Device structure in the SMBIOS information.

Status

Data type: string

Access type: Read-only

Current status of the object. Various operational and nonoperational statuses can be defined. Operational statuses include: «OK», «Degraded», and «Pred Fail» (an element, such as a SMART-enabled hard disk drive, may be functioning properly but predicting a failure in the near future). Nonoperational statuses include: «Error», «Starting», «Stopping», and «Service». The latter, «Service», could apply during mirror-resilvering of a disk, reload of a user permissions list, or other administrative work. Not all such work is online, yet the managed element is neither «OK» nor in one of the other states.

The possible values are.

OK («OK»)

Error («Error»)

Degraded («Degraded»)

Unknown («Unknown»)

Pred Fail («Pred Fail»)

Starting («Starting»)

Stopping («Stopping»)

Service («Service»)

Stressed («Stressed»)

NonRecover («NonRecover»)

No Contact («No Contact»)

Lost Comm («Lost Comm»)

Tag

Data type: string

Access type: Read-only

Unique identifier for the physical memory device that is represented by an instance of Win32_PhysicalMemory. This property is inherited from CIM_PhysicalElement.

Example: «Physical Memory 1»

TotalWidth

Data type: uint16

Access type: Read-only

Total width, in bits, of the physical memory, including check or error correction bits. If there are no error correction bits, the value in this property should match what is specified for the DataWidth property.

This value comes from the Total Width member of the Memory Device structure in the SMBIOS information.

TypeDetail

Data type: uint16

Access type: Read-only

Type of physical memory represented.

This value comes from the Type Detail member of the Memory Device structure in the SMBIOS information.

Reserved (1)

Other (2)

Unknown (4)

Fast-paged (8)

Static column (16)

Pseudo-static (32)

RAMBUS (64)

Synchronous (128)

CMOS (256)

EDO (512)

Window DRAM (1024)

Cache DRAM (2048)

Non-volatile (4096)

Version

Data type: string

Access type: Read-only

Version of the physical element.

Remarks

The Win32_PhysicalMemory class is derived from CIM_PhysicalMemory.

Examples

The Get-ComputerInfo — Query Computer Info From Local/Remote Computers — (WMI) PowerShell sample on TechNet Gallery uses a number of calls to hardware and software, including Win32_PhysicalMemory, to display information about a local or remote system.

The Server Report PowerShell sample on TechNet gallery uses a number of calls to hardware and software, including Win32_PhysicalMemory, to gather server information and publish in Word document.

The following PowerShell code sample retrieves information regarding the physical memory of the local computer.