Menu
In this answer author states:
With the 64-bit x86_64 kernel, a 32-bit process can use the entire 4GB address space, except for a couple pages (8KB) at the end of the 4GB address space which are managed by the kernel.
What is the purpose of this kernel-managed memory? Shouldn’t it be in the kernel space, to prevent accidental corruption by the user?
973
A 32-bit system can access 232 different memory addresses, i.e 4 GB of RAM or physical memory ideally, it can access more than 4 GB of RAM also. A 64-bit system can access 264 different memory addresses, i.e actually 18-Quintillion bytes of RAM.
With the two most common representations, the range is 0 through 4,294,967,295 (232 − 1) for representation as an (unsigned) binary number, and −2,147,483,648 (−231) through 2,147,483,647 (231 − 1) for representation as two's complement.
In principle, a 64-bit microprocessor can address 16 EiB (16 × 10246 = 264 = 18,446,744,073,709,551,616 bytes, or about 18.4 exabytes) of memory.
It uses up more memory for several reasons. First, you can run 32-bit applications on a 64-bit OS, which means a 64-bit OS has to load some 32-bit libraries into memory in addition to its native 64-bit libraries, which is the bulk of the memory difference.
Citing the kernel source: “Kernel pointers have redundant information, so we can use a scheme where we can return either an error code or a [...] pointer with the same return value.”
The values -1..-4095 (mapping to 0xfffff000–0xffffffff in 32-bit mode) are reserved for kernel-level errno values. The other 4KB from 0xffffe000–0xffffefff are held free for the vsyscall vdso magic page, but since the vdso page is relocatable since many moons, this area remains potentially unpopulated, that is to say, the [stack] entry in /proc/*/maps ends at 0xffffdfff always regardless of whether [vdso] is mapped at 0xffffe000 or elsewhere.
156
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
