[PATCH RFC 00/12] mm/vmalloc: migrate vmap_area indexing from rb-tree to maple-tree
Uladzislau Rezki
urezki at gmail.com
Mon Jun 15 02:52:22 PDT 2026
On Sun, Jun 14, 2026 at 12:15:28AM +0100, Matthew Wilcox wrote:
> On Sat, Jun 13, 2026 at 10:49:42PM +0530, Pranjal Arya wrote:
> > vmalloc's free/busy/lazy area tracking is one of the last remaining
> > augmented-rb_tree consumers in the core mm allocators. The rest of
> > mm/ has been gradually consolidating range-keyed indexing around
> > maple_tree (notably the per-process VMA tree in mm/mmap.c), and
> > the underlying reason is a structural mismatch between rb_tree and
> > range tracking:
>
> First, and most importantly, I love this. The maple tree is undoubtedly
> the right data structure to use for this purpose.
>
> What I don't understand is why you maintain a separate "free" tree.
> It should not be necessary any more, but maybe you tried removing it
> already and found a performance problem?
>
We maintain it in order to split several entities. That prevents
interfering between allocated data and vmap-free-space manager.
So in that case one context can easily access allocated data, for
example vread iterator, etc., whereas another can do an allocation.
So by splitting parts i minimize lock-contention.
--
Uladzislau Rezki
More information about the maple-tree
mailing list