Internal fragmentation

I made some measurements of how much internal fragmentation would grow with various page sizes and posted it on Usenet <2020Oct9.190337@mips.complang.tuwien.ac.at> Given that I no longer know a working Usenet archive, I just repost this work here:

I use the following script:

cat /proc/[1-9]*/maps|
awk '$2~/.w.p/||!$2":"$6 in m {m[$2":"$6]=1; print $1" swap - doit"}'|
sed 's/-/ /'|
gforth -e 'variable mem create ps $2000 , $4000 , $8000 , $10000 , create sums 0 , 0 , 0 , 0 , : doit 4 0 do dup ps i th @ naligned over - sums i th +! loop mem +! ; hex stdin include-file decimal : printit mem @ $400 / 8 .r 4 0 do sums i th @ $400 / 8 .r loop ; printit cr bye'

On my desktop this outputs the second of the following lines:

 total       8KB    16KB    32KB    64KB
 1040972    6676   22244   56148  124788

The 8KB column tells how many extra KB would be used if the page size
was 8KB.  Comparing total memory as determined by this script to the
output of free (555900 without buffers/cache) indicates that, on
average, only about half of the address space in a VMA is consumes
memory; so there is also quite a bit of uncertainty about my estimates
for extra memory.

For the three machines above [desktop (2h uptime, spartan user interface);
 laptop (54d uptime, Ubuntu, Gnome, 2 users); server (89d uptime, Debian,
 Gitlab and Jitsi in Docker)], I get today (numbers in KB):

VMAs unique    used     total      8KB    16KB    32KB    64KB   
 7552  2333    555964  1033320    6704   22344   56344  125144 desktop
82836 25276   5346060 15707448   76072  223000  514472 1113672 laptop
47017 15425 105490636 60186068   40804  134492  319852  708588 server

I have no explanation why used is higher than total on the server.

If you want to get an average VMA size, just divide total by unique.

In any case, even with the considerable uncertainty from partially
populated VMAs, the extra cost of 8KB or 16KB pages does not appear to
be large, even on the laptop.

L1 TLBs are as small as they are because making them larger also means that they are slower, and at some point the L1 cache access speed is limited by TLB speed. For highly or fully associative structures (as is often the case for L1 TLBs), power consumption is also an issue.