Single Process Maximum Possible Memory in X64 Linux

Single Process Maximum Possible Memory in x64 Linux

Certain kernels have different limits, but on any modern 64-bit linux the single-process limit is still far over 32GB (assuming that process is a 64-bit executable). Various distributions may also have set per-process limits using sysctl, so you'll want to check your local environment to make sure that there aren't arbitrarily low limits set (also check ipcs -l on RPM-based systems).

The Debian port documentation for the AMD64 port specifically mentions that the per-process virtual address space limit is 128TiB (twice the physical memory limit), so that should be the reasonable upper bound you're working with.

How much memory does a 64bit Linux Kernel take up?

Each user-space process can use its own 2^47 bytes (128 TiB) of virtual address space. Or more on a system with PML5 support.

The available physical RAM to back those pages is the total size of physical RAM, minus maybe 30 MiB or so that the kernel needs for its own code/data. (Not including the pagecache: Linux will use any spare pages as buffers and disk cache). This is mostly unrelated to virtual address-space limits.

---

1G is how much virtual address space a kernel used up. Not how much physical RAM.

The address-space question mattered for how much memory a single process could use at the same time, but the kernel can still use all your RAM for caching file data, etc. Unless you're finding the 2^(48-1) or 2^(57-1) bytes of the low half virtual address-space range cramped, there's no equivalent problem.

See the kernel's Documentation/x86/x86-64/mm.txt for the x86-64 virtual memory map. Also Why 4-level paging can only cover 64 TiB of physical address re: x86-64 Linux not doing inconvenient HIGHMEM stuff - the entire high half of virtual address space is reserved for the kernel, and it maps all the RAM because it's a kernel.

Virtual address space usage does indirectly set a 64 TiB limit on how much physical RAM the kernel can use, but if you have less than that there's no effect. Just like how a 32-bit kernel wasn't a problem if your machine had less than 1 or 2 GiB of RAM.

---

The amount of physical RAM actually reserved by the kernel depends on build options and modules, but might be something like 16 to 32 MiB.

Check dmesg output and look for something like this kernel log message from an x86-64 5.16.3-arch1 kernel I found in an old boot-log message.

Memory: 32538176K/33352340K available (14344K kernel code, 2040K rwdata, 8996K rodata, 1652K init, 4336K bss, 813904K reserved, 0K cma-reserved

Don't count the init (freed in after boot) or reserved parts; I'm pretty sure Linux doesn't actually reserve ~800 MiB in a way that makes it unusable for anything else.

Also look for the later Freeing unused decrypted memory: 2036K / Freeing unused kernel image (initmem) memory: 1652K etc. (That's the same size as the init part listed earlier, which is why you don't have to count it.)

It might also dynamically allocate some memory during startup; that initial "memory" line is just the sum of its .text, .data, and .bss sections, static code+data sizes.

The maximum amount of memory any single process on Windows can address

Mark Russinovich published a multipart series on windows memory resources really covers this very well. You can find it here:
http://blogs.technet.com/b/markrussinovich/archive/2008/07/21/3092070.aspx

He covers the reasons why the limits are what they are, as well as tests. The code for the tests are floating around in the tubes somewhere.

If you want to know about memory resources and the problems you can see from leaking the various types, it is a good read.

But, in a nutshell, 32 bit on 32 bit OS: 2 GB, unless set to large address space aware, in which case 3 GB. 32 bit on 64 bit OS: 2 GB, unless set to large address space aware, in which case 4 GB.

64 bit process: 2 GB, unless set to large address space aware, in which case it could address up to 8 TB, unless it is hosted on an Intel Itanium-based systems which is limited to 7 TB.

Microsoft states the various limits (by flavors and types) at:
http://msdn.microsoft.com/en-us/library/aa366778.aspx

Is there a memory limit for a single .NET process

32bit or 64bit? 32bit is 2gb (for a process), 64 bit is 1TB (enterprise edition 2003 server).

However, the maximum size of a CLR Object is 2gb even on 64bit.

Update: the information above was correct in 2008. See Ohad's answer for more recent information. Windows 2016 server can have a maximum of 24TB.

Process Memory limit of 64-bit process

The maximum memory limit for x64 processes is 8 TB, but the practical limit is far less as it depend on the amount of physical memory and the pagefile size on your system. See this post for more details on this.

The IMAGE_FILE_LARGE_ADDRESS_AWARE affect an x86 process running on a x64 OS (or a x86 OS with the /3GB directive). Your x64 application does not need to set the large address aware flag and it will be able to use all the available virtual memory on your system.

Memory Configuration for 32-bit, 64-bit and PAE enabled OS

Q.1
Ans:-

The 32-bit processor includes a 32-bit register, which can store 2^32 and the 64-bit processor includes a 64-bit register, which can store 2^64.
A 64-bit register can theoretically 16 exabytes of memory.

For 32-bit os maximum virtual memory is 4GB, it can address only up to 4GB of physical RAM (Without PAE).

For the Linux kernel, it works on virtual memory management i.e CPU address, There are many types of addresses For example. bus address, physical address(There are other concepts to access physical memory eg. DMA and IOMMU)

The virtual memory size is the maximum virtual size of a single process.

For more details of 32-bit and 64-bit processor use link.

Q.2
Ans:-

For 64-bit OS address space is 16 exabyte RAM. and generally page size is 8K i.e 2^13 (apart from that there is the concept of hugepages and hugetlb).

64-bit currently uses 48-bit physical addresses that allow you to address up to 256 TBytes of main memory. because the page table is also a page itself and consists of page table entries. Since the number of entries in one table is limited and depends on the entry size and page size, so tables are arranged in multiple levels. There are usually 2 or 3 levels, and sometimes even 4 levels.

General calculation of 64-bit os:-

 Number of entries in page table = virtual address space size/page size

                            = 2^(64-13) (if page size is 8K)

                            = 2^51 for maximum page table entries (if you are using whole 64 bits)

Page Size == Frame Size.

Q.3
Ans:-

For PAE, the page table entry expands from 32 to 36 bits. This allows more space for the physical page address, or page frame number(PFN) field, in the page table entry. In the initial implementations of PAE, the page frame number(PFN) field was expanded from 20 to 24 bits. The size of the "byte offset" from the address being translated is still 12 bits, so total physical address size increases from 32 bits to 36 bits (from 20+12 to 24+12). This increased the physical memory that is theoretically addressable by the CPU from 4 GB to 64 GB.

Maximum size of PAE is = 64GB (2^36).

For PAE in details use link

---

Related Topics