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 0241AC433F5 for ; Sun, 1 May 2022 23:56:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F04FD6B0072; Sun, 1 May 2022 19:56:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EB37B6B0073; Sun, 1 May 2022 19:56:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA11B6B0074; Sun, 1 May 2022 19:56:41 -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 C84DA6B0072 for ; Sun, 1 May 2022 19:56:41 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 9D03660DB3 for ; Sun, 1 May 2022 23:56:41 +0000 (UTC) X-FDA: 79418836602.06.4D6A0BD Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf01.hostedemail.com (Postfix) with ESMTP id ECE6F40077 for ; Sun, 1 May 2022 23:56:33 +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 BA53D60F89; Sun, 1 May 2022 23:56:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BB327C385AE; Sun, 1 May 2022 23:56:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1651449399; bh=E3IU7wp+u3xButnlu57iaqCHUQJvl7jir8ysbnCd3lI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=EFR6Rgf+Ae6rGv1Wap4GiK0sCiqyhF/2eM2nybh6VJDsGTrMwxKAUt3FpuJ8rupEO tjWFXoJi+JdomJfFCdlmlzTlXen/XmBrzdIR5siEDIOJK17fhC+b1NOWcwHz7O2IKB hejdCuxWt8/k3ikeUgQbMj7l18qea9I8+RKjjjcs= Date: Sun, 1 May 2022 16:56:33 -0700 From: Andrew Morton To: Davidlohr Bueso Cc: Matthew Wilcox , Liam Howlett , "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: <20220501165633.056319565dce429e36d25a0a@linux-foundation.org> In-Reply-To: <20220501202532.y6zmznzshbe33nwx@offworld> References: <20220426150616.3937571-1-Liam.Howlett@oracle.com> <20220426130857.09f40743b42b5f0bf4f19a59@linux-foundation.org> <20220427140832.mpvnnkkhrbupk46i@revolver> <20220427103331.9876ad87626af0f50e9ced0d@linux-foundation.org> <20220501202532.y6zmznzshbe33nwx@offworld> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=EFR6Rgf+; dmarc=none; spf=pass (imf01.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: ECE6F40077 X-Rspam-User: X-Stat-Signature: acr6bap98dg46mn85kj8dtmguquyjycb X-HE-Tag: 1651449393-625975 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 Sun, 1 May 2022 13:26:34 -0700 Davidlohr Bueso wrote: > On Wed, 27 Apr 2022, Matthew Wilcox wrote: > > >On Wed, Apr 27, 2022 at 10:33:31AM -0700, Andrew Morton wrote: > >> On Wed, 27 Apr 2022 14:08:39 +0000 Liam Howlett wrote: > >> > 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? > > > >Yes, performance-wise it's a wash. However, Davidlohr was very > >impressed that it was a wash because we're actually getting rid of three > >data structures here; the linked list, the rbtree and the vmacache. > >His opinion was that we should push the maple tree in now, in advance > >of the future RCU uses. > > Yes I like the maple tree, and at this stage I don't think we can ask > for more from this series wrt the MM - albeit there seems to still be > some folks reporting breakage. Fundamentally I see Liam's work to (re)move > complexity out of the MM (not to say that the actual maple tree is not > complex) by consolidating the three complimentary data structures very > much worth it considering performance does not take a hit. This was > very much a turn off with the range locking approach, which worst case > scenario incurred in prohibitive overhead. Also as Liam and Matthew > have mentioned, RCU opens up a lot of nice performance opportunities, > and in addition academia[1] has shown outstanding scalability of address > spaces with the foundation of replacing the locked rbtree with RCU > aware trees. Thanks. That sounded like a wordy acked-by to me? :) Liam, I think the above is useful background for the [0/N]. > [1] https://pdos.csail.mit.edu/papers/rcuvm:asplos12.pdf As is that. The paper seems shockingly relevant. Do we know the authors or is it a cosmic coincidence?