[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