Convert KiB to GiB

A kibibyte is exactly 1,024 bytes. The name was coined in 1998 precisely so that "kilobyte" could go back to meaning 1,000, though the habit never fully took.

A gibibyte is 1,073,741,824 bytes — about 7% more than a gigabyte. Windows measures in gibibytes and labels them GB, which is the whole of the missing-space mystery.

Going this way is a division, and by a whole number: 1,048,576 of these fit into one gibibyte with nothing left over. The awkwardness is only that the answers come out as fractions — a third of a gibibyte, a twelfth of one — rather than as the round figures the other direction gives you.

Nothing is lost to rounding even so. The division is exact, and if your answer will not sit still as a decimal — 0.0833… and friends — that is the fraction showing through, not an error creeping in.

One KiB is 1,024 of the unit below it; one kB is 1,000. On this page that is the difference between 0 GiB and 0 GiB — 2.4 % — and the gap grows at every step up the scale, which is why it is a rounding error on a photograph and a visible chunk of a hard disk.

This is the whole of the missing-storage mystery, and on this page it is worth 2.4 %. A drive sold in kB holds exactly what the label says; Windows divides by 1,024 instead of 1,000, keeps the decimal name, and reports 0 GiB where the box said 0. macOS has counted these in the decimal units since 10.6, which is why the same drive can look two sizes on two machines — nothing is missing and nobody is rounding, the same bytes have two names.

Every value in /proc/meminfo is a count of 1,024-byte units printed under a label reading kB, and the same is true of /proc/swaps, the per-node meminfo files under /sys, and the memory sysctls. The label predates the kibibyte having a name, and changing it now would break every script that has ever parsed the file, so it stays wrong and everybody who reads it programmatically knows to ignore it.

The consequence for anybody converting by hand is a 2.4 per cent error at the first step and 7.4 per cent by the time it reaches gibibytes, in the direction that makes the machine look smaller than it is. Taking MemTotal at 16,316,480 and dividing by a million gives 16.3 "GB"; dividing by 1,048,576 gives 15.56 GiB, and it is the second figure that will match what every other tool on the box reports.

On a hard drive the decimal figure is the manufacturer's and the binary figure is the operating system's, and neither is more correct than the other — they are two ways of counting the same bytes. Memory is not like that. A memory array is selected by address lines, n of them decoding 2ⁿ locations, so capacities fall on powers of two because anything else would leave part of the address space decoding nothing.

That makes 8 GiB the true size of an 8 GB module: 8,589,934,592 bytes, with the decimal label the approximation rather than the reality. It is the reason a memory figure and a storage figure of the same nominal size are not the same quantity of bytes, and the reason converting a kibibyte memory count into GiB gives a round number while converting a disk figure almost never does.

The gap is real and it is itemised rather than mysterious. Firmware reserves regions below 1 MiB and around the ACPI tables; integrated graphics take a fixed carve-out that can run to a gibibyte on a laptop; the kernel image, the page tables and the memory map for the machine itself come off the top before MemTotal is computed. dmesg | grep -i memory shows the reservations at boot.

A 16 GiB laptop reporting 15.56 GiB has therefore lost around 450 MiB, or 460,736 KiB, and it is worth converting the difference rather than the total when the question is "where did it go". A server with error-correcting memory loses a further one part in eight to the check bits, though that share is invisible to the kernel and never appears in the kibibyte figure at all.

The ratio is 1,048,576, which is close enough to a million that dropping six digits gives an estimate within five per cent. A MemTotal of 32,633,240 KiB reads as "about 32.6", and the true figure is 31.12 GiB — low by about the same 4.6 per cent every time, so the correction is a fixed one rather than something to work out afresh.

For a figure that has to be right, count the commas instead. Kibibytes to mebibytes is three commas back and a small correction; mebibytes to gibibytes the same again. Doing it in two ten-bit steps is easier to check than one twenty-bit step, and it puts the mebibyte figure in front of you, which is the unit most container and JVM settings want anyway.

Ordinary memory pages are 4 KiB on x86-64 and huge pages are 2 MiB, reported by the kernel as Hugepagesize: 2048 kB. A pool declared as 2,048 huge pages is 4,194,304 KiB, which is exactly 4 GiB — the arithmetic stays clean because every quantity involved is a power of two, which is the whole reason huge pages are sized the way they are.

It stops being clean when somebody sets the pool from a percentage. Reserving "about a third" of a 62 GiB machine gives 10,600 pages, or 21,708,800 KiB, or 20.7 GiB, and the awkward gibibyte figure is the tell that the number came from a percentage rather than from a workload. Databases and virtual machines that want huge pages generally want a specific figure, and it is easier to state it in GiB and convert down.

/proc/swaps reports its Size column in 1,024-byte blocks, so an 8,388,604-block swap file is 8 GiB less four blocks — the missing four kibibytes are the header the swap area writes at the front. swapon --show prints the human-readable form and hides the detail, which is fine for reading and misleading if you are trying to work out why the file you created came back four kibibytes short.

The tuning knobs stay in kibibytes too. vm.min_free_kbytes sets the reserve the allocator will not dip into, commonly around 67,584 on a desktop, which is 66 MiB or 0.06 GiB — an amount small enough that the gibibyte figure is useless and the kibibyte one is the right unit to think in. Convert to check the order of magnitude, then leave the field as it was.

The same computer reports its memory in binary units labelled decimally and its storage in decimal units relabelled binarily, and the two habits meet in the middle with no warning. A machine described as 16 GB RAM and 512 GB SSD holds 17.18 billion bytes of memory and 512 billion bytes of disk, and the disk will show as 476.8 GiB while the memory shows as very nearly 16.

The practical rule is which party did the labelling. Where a manufacturer chose the number — drives, phone storage, network speeds — it is decimal and the binary figure will look short. Where the hardware chose it — memory modules, page sizes, cache lines, address spaces — it is binary and the decimal figure is the rounding. A kibibyte count from the kernel is always the second kind.