THE FOLD / SPAWN / THE SANDBOX / THE HUGE PAGE
THE HUGE PAGE
it helps most where it is needed least
1 WHAT IT IS · WHAT IT DOES · FACT OR FICTION
A bigger page means fewer translations to track. It also means every allocation rounds up to a bigger boundary, and the rounding is charged whether you asked for it or not.
LIT verified live. 4,000 allocations totalling 5,919,648,648 bytes. With 4 KB pages: 1,447,224 pages and 0.14% internal waste. With 2 MB pages: 5,159 pages — 280.5× fewer — and 82.77% waste. The page table shrinks by two and a half orders of magnitude and the memory bill rises by a factor of six.
LIT verified live. 4,000 allocations totalling 5,919,648,648 bytes. With 4 KB pages: 1,447,224 pages and 0.14% internal waste. With 2 MB pages: 5,159 pages — 280.5× fewer — and 82.77% waste. The page table shrinks by two and a half orders of magnitude and the memory bill rises by a factor of six.
2 HOW IT WAS WEAVED · AI + HUMAN
Transparent huge pages are on by default in most Linux distributions, and periodically turned off by database vendors for exactly this reason.
AVAN (AI) measured both columns from one allocation trace so the trade is a single fact rather than two arguments. 82.77% is what a workload of many small objects pays; a workload of few large ones pays almost nothing. Neither number is a verdict on huge pages — the size distribution is, and it is the thing nobody measures before flipping the switch.
AVAN (AI) measured both columns from one allocation trace so the trade is a single fact rather than two arguments. 82.77% is what a workload of many small objects pays; a workload of few large ones pays almost nothing. Neither number is a verdict on huge pages — the size distribution is, and it is the thing nobody measures before flipping the switch.
3 ONE DIMENSION
Pages tracked, and bytes wasted, for the same trace.
4 TWO DIMENSIONS · INTERACTIVE
Shift the allocation size and watch the trade invert.
5 THREE DIMENSIONS + AVAN’S INVERSE
The green forward object: fewer, larger boxes.
AVAN’s addition (the inverse-companion): the forward reading is that huge pages trade memory for translation speed. The inverse is that they charge the workload that can least afford it. The programs with many small allocations are the ones with poor locality, which are the ones huge pages were meant to rescue — and they are the ones that pay 82.77%. Read backwards, the optimisation helps most where it is needed least, which is the usual shape of anything applied globally to a distribution nobody looked at.
LIT 4,000 allocations totalling 5,919,648,648 bytes take 1,447,224 pages and waste 0.14% at 4 KB, against 5,159 pages - 280.5 times fewer - and 82.77% waste at 2 MB: the page table shrinks by two and a half orders of magnitude while the memory bill rises by a factor of six
FIG Transparent huge pages are on by default in most Linux distributions and periodically turned off by database vendors for exactly this reason. AVAN measured both columns from one allocation trace so the trade is a single fact rather than two arguments. 82.77% is what a workload of many small objects pays and a workload of few large ones pays almost nothing - neither number is a verdict on huge pages, the size distribution is, and it is the thing nobody measures before flipping the switch.
FIG Transparent huge pages are on by default in most Linux distributions and periodically turned off by database vendors for exactly this reason. AVAN measured both columns from one allocation trace so the trade is a single fact rather than two arguments. 82.77% is what a workload of many small objects pays and a workload of few large ones pays almost nothing - neither number is a verdict on huge pages, the size distribution is, and it is the thing nobody measures before flipping the switch.
◆ sealed .dlw.fold → folded to ROOT_0 · a sphere of THE SANDBOX · David Lee Wise (ROOT0), with AVAN