# MLX buffer pool reuse window and cache sizing (mlx issue 3886) > The reuse test is `it->first >= min(2*size, size + 2*page_size_)` returns nullptr, so for buffers over about 32 KB the window is [size, size + 2 pages). Parent: [Mac local LLMs: Memory and wired limits](https://llms-explorer.com/tree/mac-local-llms-memory-and-wired-limits/) · 1 facets · 8 facts · page: https://llms-explorer.com/tree/mlx-buffer-pool-reuse-window-and-cache-sizing-ml/ ## Facts - The reuse test is `it->first >= min(2*size, size + 2*page_size_)` returns nullptr, so for buffers over about 32 KB the window is [size, size + 2 pages). — [source](https://github.com/ml-explore/mlx/issues/3886) - Appending one position to 10 K/V pairs of [4, N, 512] bf16 per step cost 1.19/1.28/1.74/3.12 ms at ctx 512/1024/2048/4096 with growing concatenate, 0.58/0.82/1.13/1.96 ms with constant-size concatenate, and 0.38/0.36/0.35/0.35 ms with preallocated slice_update. — [source](https://github.com/ml-explore/mlx/issues/3886) - The reporter extrapolates growing concatenate on a 60-layer Gemma-4-31B to about 50 ms per token at 4096 context. — [source](https://github.com/ml-explore/mlx/issues/3886) - mlx-lm's Python KVCache avoids the trap by preallocating in 256-step chunks and using slice_update. — [source](https://github.com/ml-explore/mlx/issues/3886) - After a growing-cache phase, unrelated workloads ran 10 to 35 percent slower until process exit because the pool held never-reusable sizes. — [source](https://github.com/ml-explore/mlx/issues/3886) - The reporter's engine fix was chunk-preallocated buffers plus slice_update, where donation makes the append in place. — [source](https://github.com/ml-explore/mlx/issues/3886) - zcbenz closed issue 3886 on 2026-08-08 as won't fix, citing the preallocated-slice requirement of cuDNN SDPA. — [source](https://github.com/ml-explore/mlx/issues/3886) - Issue 3886 is a different issue from 3896 and the existing dossier's pointer to it is a second-hand citation. — source: `asserted`