the page size
Think of moving sand with buckets. Tiny teacups waste almost no sand at the top of the last cup, but you make a thousand trips and keep a huge tally of which cup went where. One giant barrel makes a single trip with a tiny tally, but if you only had a handful of sand the barrel is mostly empty — wasted. The PAGE SIZE is the size of the bucket for memory, and choosing it is exactly this trade-off: small pages waste little but need big bookkeeping; large pages need little bookkeeping but waste more in the last partial page.
Concretely, the page size is the fixed number of bytes in one page and frame, always a power of two (commonly 4 KB; 'huge pages' of 2 MB or 1 GB also exist). The size determines how a logical address splits: a page of 2^n bytes means n bits of offset and the rest as page number. Making pages SMALLER has two effects: less INTERNAL fragmentation, because the wasted tail in the last page is at most one page minus one byte (so on average half a small page); but the page table has MORE entries (more pages to map a given address space), and the TLB, which holds a fixed number of entries, covers LESS total memory, so it misses more often. Making pages LARGER reverses both: less table overhead and far more memory covered per TLB entry (great for big working sets), but more internal fragmentation and coarser granularity for protection, sharing, and (in virtual memory) disk transfer.
Page size matters because it is a real tuning knob with no free lunch: there is no single best value, only a balance for the workload. Modern systems often support a small default page plus optional huge pages, letting a database or scientific program with a large, dense working set use huge pages to slash TLB misses, while ordinary programs keep small pages to limit waste. A common misconception is that bigger pages are simply 'faster' — they reduce TLB pressure, yes, but they waste more memory to internal fragmentation and can make fine-grained sharing and paging clumsier, so the right size genuinely depends on what the program does.
A program touches 4 MB of data scattered across many pages. With 4 KB pages it spans 1024 pages, far more than a 64-entry TLB can cover, so it misses constantly. Switch to 2 MB huge pages and the same 4 MB needs just 2 pages — both fit in the TLB easily, eliminating the misses, at the cost of wasting up to nearly 2 MB if the last huge page is barely used.
Larger pages cover more memory per TLB entry (fewer misses) but waste more in the last partial page — a genuine trade-off.
Bigger pages are not simply 'faster': they cut TLB misses and table overhead but raise internal fragmentation and coarsen sharing and protection. There is no universally best page size, only the right balance for a given workload.