best-fit
Imagine choosing a storage box for an awkward object by trying every box and picking the smallest one it still fits in, so you waste the least empty space. Best-fit is that instinct applied to memory: among all the holes big enough to hold the process, pick the smallest one.
Concretely, when a process of size S arrives, best-fit must scan the entire free list (unless the list is kept sorted by size) to find the smallest hole whose size is at least S, then allocate S bytes from it. The leftover sliver (hole size minus S) becomes a new tiny hole. The intuition is that by always using the tightest-fitting hole, you avoid breaking up a large hole that some future big process might need.
Why it matters: best-fit is the strategy people reach for first because it sounds obviously thrifty — but reality disagrees. Studies and simulations show best-fit is slower (it must examine every hole) and, surprisingly, it does not save memory overall; in fact it tends to leave behind a litter of slivers too small to be useful, which is its own kind of external fragmentation. It is a classic lesson that the locally optimal choice (least waste right now) is not globally optimal.
Holes: 50 KB, 200 KB, 120 KB. A 100 KB request examines all three and picks the 120 KB hole (smallest that fits), leaving a 20 KB sliver — a fragment likely too small for the next request to use.
Tightest fit now, but it manufactures tiny unusable leftovers.
Despite its name, best-fit is usually not the best in practice: it is slower than first-fit and tends to litter memory with unusable slivers. The name describes the choice it makes, not its results.