Therefore, there is no portable way to obtain that information that is guaranteed to work, because some platforms might not even provide it at all. Only if the kernel has/needs drivers that interact with the physical memory controller directly, or gets platform metadata such as via DMI, is this information readily available.
Building systems that rely on looking round the curtain to the hardware has a habit of breaking when new hardware appears that does something surprising.
None of the operating system kernels I know of (including Linux, all the BSDs, and Microsoft Windows) program the physical memory controller; it's always done by the platform firmware while running from ROM or cache-as-RAM, before the operating system kernel is loaded into RAM.
Windows is harder to find (not open source) but issue tracking indicates it has one: https://www.intel.com/content/www/us/en/support/articles/000...
Of course the bootloaders all set up RAM. They have to, to load the operating system. Then the OS sets it up again, to suit itself.
The obvious explanation is the PCI window. Looking at the memoryN/valid_zones file, I can see on my machine that the ones below memory32 have DMA32, while the ones above have Normal; DMA32 is the zone with memory below 4G, while Normal is the zone with memory above 4G. There's a window at the top of the 32-bit physical address space where most PCI devices are mapped; you can see these mappings by looking at /proc/iomem (as root, since the addresses are masked otherwise).
That is, the physical memory which should be at that hole was instead remapped to somewhere else (otherwise it would have been wasted); the directories above memory127 probably correspond to that remapped memory.
The most relevant kernel code is here:
I am one of the original authors listed at the top of that file.
Experience with several hundred-node clusters is that the hardware doesn't obey the conservation law many people assume. It's not that uncommon to find cores and DIMMs disappearing from "sight" -- or being absent initially and not spotted by the vendor. (I've yet to see an HPC cluster vendor that understands real system management.)
> On systems with hot-swappable RAM, memoryN/state might be “offline”,
Anyone have any information on this or real world use cases not better suited for having a cluster or multiple redundant machines? Are these still prevalent in some markets 2020? Looks like, according to really bad results in teh googs, CPUS are hot-swappable too? Is it a an extra socket on the motherboard or like some sort of franken dual-board setup?
I'm more curious than anything how systems like that are used or what their niche is... I'm sure they're insanely impractical for almost any conceivable purpose but what are those few cases they aren't? What's it like swapping out a CPU or DIMM in those? Just a lot of holding onto your butt and praying?
There wasn't a particular niche for this equipment, it was just intended to be repairable while in service. At the time, it was typical to spend a larger dollar amount on equipment which was manufactured for very high serviceability. A combination of improvement in the actual reliability of hardware, increasing cost pressure, and probably as the lesser factor a shift towards more horizontal architectures (where redundancy was across machines instead of across components in machines) has made this a lot less common, although still not at all unheard of on high-end equipment.
Actually removing and replacing these parts while the system runs requires electrical and mechanical features that most machine lack.
I searched around a bit more and I now suspect the 2GB slot might actually support 4GB, but I don't want to spend money on this bet (it's an old machine with a Core 2 Duo processor).
So now I'm left wondering how dmidecode can be so wrong.
e.g. If you were pre-allocating hash tables for a caching service, it would be convenient if the config could stipulate 80% of the system memory instead of the user having to specify the exact amount.
There is no interface for that information because at the level of abstraction at which userspace applications operate, that information has no meaning.