From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 734DDC433F5 for ; Wed, 27 Apr 2022 17:33:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE3386B0071; Wed, 27 Apr 2022 13:33:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A94A86B0073; Wed, 27 Apr 2022 13:33:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9597D6B0074; Wed, 27 Apr 2022 13:33:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 85BDB6B0071 for ; Wed, 27 Apr 2022 13:33:34 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1F024215FD for ; Wed, 27 Apr 2022 17:33:34 +0000 (UTC) X-FDA: 79403355948.27.60A05D9 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf29.hostedemail.com (Postfix) with ESMTP id 87FCC120064 for ; Wed, 27 Apr 2022 17:33:30 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 769FF61E4B; Wed, 27 Apr 2022 17:33:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B40F3C385A7; Wed, 27 Apr 2022 17:33:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1651080811; bh=O7AppN2/GeSeVztx+YVjK3Wc9TzGWKgcYLWspYyO5xk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=C7m9PX5lzopGA6xPav9eZkeUHRA4Di6MOlOidDzWtG347twpfec2w/FTNKix1t5fh tmMH+JSus+PJ0OrO4g+8RmHyFcYXQd/uih3ORIp+3E6hSx+SxtMMhakkUTphOQKJAi p1+bdXIBPJrLvWPXx2Y3mRKbqxRSRYJXQdc0X1cs= Date: Wed, 27 Apr 2022 10:33:31 -0700 From: Andrew Morton To: Liam Howlett Cc: "maple-tree@lists.infradead.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Yu Zhao Subject: Re: [PATCH v8 00/70] Introducing the Maple Tree Message-Id: <20220427103331.9876ad87626af0f50e9ced0d@linux-foundation.org> In-Reply-To: <20220427140832.mpvnnkkhrbupk46i@revolver> References: <20220426150616.3937571-1-Liam.Howlett@oracle.com> <20220426130857.09f40743b42b5f0bf4f19a59@linux-foundation.org> <20220427140832.mpvnnkkhrbupk46i@revolver> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 87FCC120064 X-Stat-Signature: 37ehionwt3bg5gewy9k8ngkd75ntocce X-Rspam-User: Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=C7m9PX5l; spf=pass (imf29.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-HE-Tag: 1651080810-975501 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 27 Apr 2022 14:08:39 +0000 Liam Howlett wrote: > > > > > > The tree has a branching factor of 10 for non-leaf nodes and 16 for leaf > > > nodes. With the increased branching factor, it is significantly shorter than > > > the rbtree so it has fewer cache misses. The removal of the linked list > > > between subsequent entries also reduces the cache misses and the need to pull > > > in the previous and next VMA during many tree alterations. > > > > Do we have any quantitative testing results? > > I was waiting for the mmtests sweep to complete before sending them but > I didn't want to hold up Yu Zhao's testing of the combined tree as it > has proved useful already. Please don't include the results in the first > commit as it wouldn't make much sense. If you intend to put them in a > commit message, please put them in the patch introducing the maple tree. I did that. > The benchmarks are around the same as they have always been. So it's presently a wash. That makes "the plan" (below) really critical, otherwise there seems little point in merging this code at this time? Please send me many very soothing words about how confident we should be that the plan will be implemented and that it shall be good? > > > > What's the plan on utilizing this to further reduce mmap_lock contention? > > The plan is to get to the point where we use the maple tree in RCU mode. > Readers will not block for writers. A single write operation will be > allowed at a time. A reader re-walks if stale data is encountered. VMAs > would be RCU enabled and this mode would be entered once multiple tasks > are using the mm_struct. I can go into more details if you want. Uh, that's very important information. It's really the whole point of the patchset! I added this to the [0/n] changelog.