worst-fit

Imagine always cutting your cloth from the biggest bolt on the shelf, on the theory that the leftover piece will still be large enough to be useful for someone else later. Worst-fit is that contrarian idea: among all the holes big enough, pick the largest one — the opposite of best-fit.

Concretely, when a process of size S arrives, worst-fit scans the free list to find the largest hole, allocates S bytes from it, and leaves the remainder as a hole. The reasoning is that allocating from the largest hole leaves the biggest possible leftover, which is more likely to still be useful for a future process — rather than producing a tiny unusable sliver the way best-fit does. So it deliberately spreads allocations across the big holes.

Why it matters: worst-fit is mostly of theoretical and teaching interest. In simulations it performs the worst of the three on both speed (it must scan the whole list, like best-fit) and memory use, because it quickly consumes the large holes that big processes need, leaving medium-sized holes everywhere. Studying it alongside first-fit and best-fit makes the real lesson clear: no contiguous-allocation policy beats external fragmentation — they only redistribute the wasted space differently.