= Largest free memory block
{title2=$L_{\max}$}
The <largest free memory block> is the longest contiguous free region available within a specified allocation pool and address space. If free-block lengths are $s_1,\ldots,s_n$,
$$
L_{\max}=\max_i s_i,\qquad F_{\rm free}=\sum_i s_i.
$$
For an empty free-block set, take $L_{\max}=0$. The largest block and total free capacity answer different questions: a contiguous request can fail even when $F_{\rm free}$ exceeds its size. This is the central layout issue in <external memory fragmentation>.<Operating Systems: Three Easy Pieces by Remzi H. Arpaci-Dusseau and others>[Chapter17 introduction, fragmented free capacity versus one contiguous allocation; §17.2, adjacent-block merging]{ref}
For free lengths24,40 and16 <bytes>, $F_{\rm free}=80$ <bytes> and $L_{\max}=40$ <bytes>. A48-<byte> contiguous request fails in that fixed, nonmoving pool before metadata and <memory alignment> are considered. Coalescing an additional freed separator can increase $L_{\max}$ without requiring the allocator to obtain another region from the <operating system>.
Raw extent length can overstate payload capacity. For a block $[a,b)$, an illustrative header requirement $h$ and payload alignment $A$, choose aligned payload start
$$
p=A\left\lceil\frac{a+h}{A}\right\rceil.
$$
The <aligned free-block capacity> in this simple layout is $\max(b-p,0)$. A32-<byte> block starting at0 with an8-<byte> header and16-<byte> payload alignment has $p=16$ and only16 <bytes> of payload capacity. A24-<byte> payload therefore fails despite a raw32-<byte> extent. Actual allocator layouts can impose further constraints.
The quantity also depends on the allocation layer. A large virtually contiguous block need not occupy contiguous physical <page frames>. Comparing $L_{\max}$ values without specifying virtual versus physical space, allocator pool and usable payload convention can therefore mix distinct fragmentation problems.
Back to article page
