From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 716193C06; Sat, 13 Jun 2026 23:15:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781392538; cv=none; b=RBI9qPo0FLF/F/4xbA0Vc5dN/UFsSm4rMh05qYr0D19mC429JAoe98qhAj6dnC8TOZqwGHO0jFMv1brCta92v25tiAESGzvnzkvoA6NOrcu1BMCnuWKljwsOyKsoUdzdV0StEJNQelbS3kkJVd+aWngrx7Ci6rJHTyiNKXxXzV8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781392538; c=relaxed/simple; bh=oRCbb7uF19rBpg+kFz0Ksuzjghw5gzUWnmeats7BJ0w=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OStR7WPDfwuaekZL7iYOHmoWeJmfxeHr5mc2Ic2WWtajYzmHq8AUR4ftKqIfaPGL6iZ8/TzuxDtYLUEIWxxMEMqgLGQjbFF03a8q74QS8pPYi4UjaljFiCmMjXdSpwwsra5dpbH/YX4d69qjbyzEBaYqW8L+ZRAso4jad47gi+I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=hLXD7eOS; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="hLXD7eOS" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=dG3xiqATit6gEoZb/SAPMSkQ9RbQB4Q9JV9vSc+U8/U=; b=hLXD7eOSFoc4e2VKrlStDVD/Du Rr+P17+rwokxTAhVCNohqPP9xa8dwN5Gi99qnUYhjXMy1K2Er6rjVlTluAYt0GL2ig88zArVF+8DL 1/r8ywXcf5yEuOG0JnPadEGtjy5v63TLkLSQ70KRMIuWmvKKakX7q1pHwcg1DfEk4IeZ/S6IqkYln kK9hiVzrvTJZ/6d9Odoqp+g1zWurLoBhkgzSKTtbcDwye5KDzjdlm+L9hX3dMprypCjS5+1y1JLrS xwqZskhRqi/p1tQ841bYJ3x4SRVontkg24HJu8IqA2hPgNMB4hyDySHxDiw4H7B/Tgi2UkDMmFTXs EFlnYPnA==; Received: from willy by casper.infradead.org with local (Exim 4.99.1 #2 (Red Hat Linux)) id 1wYXZY-00000006DCZ-3ADY; Sat, 13 Jun 2026 23:15:28 +0000 Date: Sun, 14 Jun 2026 00:15:28 +0100 From: Matthew Wilcox To: Pranjal Arya Cc: Andrew Morton , Uladzislau Rezki , "Liam R. Howlett" , Alice Ryhl , Andrew Ballance , linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, maple-tree@lists.infradead.org, Lorenzo Stoakes , Pranjal Shrivastava , Will Deacon , Suzuki K Poulose , Neil Armstrong , Mostafa Saleh , Balbir Singh , Suren Baghdasaryan , Marco Elver , Dmitry Vyukov , Alexander Potapenko , Shuah Khan , Dev Jain , Brendan Jackman , Puranjay Mohan , Santosh Shukla , Wyes Karny , Sudeep Holla Subject: Re: [PATCH RFC 00/12] mm/vmalloc: migrate vmap_area indexing from rb-tree to maple-tree Message-ID: References: <20260613-vmalloc_maple-v1-0-0aa740bb944b@oss.qualcomm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260613-vmalloc_maple-v1-0-0aa740bb944b@oss.qualcomm.com> 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?