Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp3708596pxb; Fri, 4 Feb 2022 14:44:12 -0800 (PST) X-Google-Smtp-Source: ABdhPJxW+8bBhMQyxXckMK+YBOWHpuEAVmeI0W3Z2dhN+TXFK21K8NtFgN+dQD5zMdNo7Llkce+k X-Received: by 2002:a17:902:c40b:: with SMTP id k11mr5162437plk.94.1644014651812; Fri, 04 Feb 2022 14:44:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644014651; cv=none; d=google.com; s=arc-20160816; b=F3b8Kt8FWHh0BvnJR3m0lkEp3xrAC9CcKOSaerparZnMR/C0Ttww4CRhsI/AWtriVv /2iPytRG+1dlDDf9mWouRTReOAc/u4KPOpV0+Roi8VCKFxEdFrMadFnSyylbRy9v6dPM TvMYgw4s4gvzR4rB9gS5cbPZXf3d/SthparPqh9iarLxu+7jFNz1uiWTQiskcRRGNOX3 QyrfhGLcEuNKzPomxfdKFa8AB5pnntjDG8Iy+I2z/X3x12FFqHhR5cooq/T7wbImJaQd 0zRJVUXGXAhWQmFyGNkKflcZSnQ28XZMaBl2++9dVJWP6J1vX+CPKUSp169qpRIaXvC+ 4Kjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=yQV3gPl1yDUBgxhny6R2vDhSuqKPXgGrUGZ3acHuiKk=; b=U7KsmMZOQpIqpPhsqaO1GdYIJJBuxGBozsLuyANERefUjupN4GH9jXar816ivWOwnD YI1Em2KzVYTf4GGK8RVfxzLzrD4zCVfP7bJ25aEhDzKmiLES14/5k/0AbKWPrk9icdQo m7dNGDEldrkpLG0wsjE2nNYHYoKeOCgyr1WYt1Id8Q1TJLmfCcb4mQfi8aVOyPGspXsV vXecpEx4qTgj4ji36aPEWLH6yvU8e8LoeJ4VdxA/qT5VV/zzIMoOBQs3UhUKiP/LJaX0 GUVdcNwatgYQq2taPHEVFweh8NIV5TDfnOmqayljg3I6Jm04dIjYsLvf5fETDF3Gp1c0 kdLA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@googlemail.com header.s=20210112 header.b="f/Gne2cE"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t19si3418000pgu.36.2022.02.04.14.43.59; Fri, 04 Feb 2022 14:44:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@googlemail.com header.s=20210112 header.b="f/Gne2cE"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352010AbiBCQC7 (ORCPT + 99 others); Thu, 3 Feb 2022 11:02:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51052 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230457AbiBCQC5 (ORCPT ); Thu, 3 Feb 2022 11:02:57 -0500 Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5588BC061714 for ; Thu, 3 Feb 2022 08:02:56 -0800 (PST) Received: by mail-ua1-x92b.google.com with SMTP id m90so6041506uam.2 for ; Thu, 03 Feb 2022 08:02:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yQV3gPl1yDUBgxhny6R2vDhSuqKPXgGrUGZ3acHuiKk=; b=f/Gne2cEJE032CfqiT7wIXCMdEMeDWaNJaLR0uJbv/ll95V4w9Muj9+2Dt+ZFGTzIK ZT0l0HlLnM5cR4zkia5kROkDaIeFVJXpm5sjYGPQpxHGVfBJo4PQwkCFB+YE5/OqxFKR WbKW8TcLvT38g0muYFRVMgWjPY5EBGj2/a5/onaMv3+av491P+ABP/UovecDJkMIxIK6 TVSo/g+g4mHE+K06lvS0qQobDByynd+Njzk9WMCQQ0WDF053NsNl67QNSqrDUIfunIaK 4kZ3IHjk2ZCYsnFVjDyoaDKaWhI0/GeWokBMv3cSnVDCXpcu3F3RvxJSvR0JCLau8HtS dyqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yQV3gPl1yDUBgxhny6R2vDhSuqKPXgGrUGZ3acHuiKk=; b=f7HmBFQna+YIwz3Sz49qODuOZuJx2Qx2L7MXwV3PCtn3CsxXVP1YQi823eXvD/PqKT fphh3fgs8YClGBW8cIncoxGz1L32+aUDDUrMzgaebWIMIDLiTP9LQsqHTVIOBzyffueI wbIeYzsLYtYzV7dl4wwOS9D1EccNfSDtAw+dsfJJw13tAcYv5rVJ61o/cYtE3+/Y4wuI 280g+06txF+HNGBvIvkZnG8dHx6d8KpkbXWnlqob6NCN5EP/+qFZ9PRIjiJ0R132OapW t6QVWgzzmY0puwjtpxdg5hQ3w49yh6Og84W4rVNmB0mnnX6bET/oq+aq0Uit82Bnf5bT rZyw== X-Gm-Message-State: AOAM530ugnqzYkzfITiJmHuM3Jq6nqFcfEdM/jBd9Y6wnMoYTv2AKvP5 dtgc4F+Aqn1izcRt2rv3Rdk/GjfLOrljSyRI1VfNChDYNHw= X-Received: by 2002:ab0:6398:: with SMTP id y24mr8266775uao.92.1643904175454; Thu, 03 Feb 2022 08:02:55 -0800 (PST) MIME-Version: 1.0 References: <20220202024137.2516438-1-Liam.Howlett@oracle.com> <20220202024137.2516438-8-Liam.Howlett@oracle.com> In-Reply-To: <20220202024137.2516438-8-Liam.Howlett@oracle.com> From: Mark Hemment Date: Thu, 3 Feb 2022 16:02:43 +0000 Message-ID: Subject: Re: [PATCH v5 07/70] Maple Tree: Add new data structure To: Liam Howlett Cc: "maple-tree@lists.infradead.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Andrew Morton Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2 Feb 2022 at 02:42, Liam Howlett wrote: > > From: "Liam R. Howlett" > > The maple tree is an RCU-safe range based B-tree designed to use modern > processor cache efficiently. There are a number of places in the kernel > that a non-overlapping range-based tree would be beneficial, especially > one with a simple interface. The first user that is covered in this > patch set is the vm_area_struct, where three data structures are > replaced by the maple tree: the augmented rbtree, the vma cache, and the > linked list of VMAs in the mm_struct. The long term goal is to reduce > or remove the mmap_sem contention. > > 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. > > Signed-off-by: Matthew Wilcox (Oracle) > Signed-off-by: Liam R. Howlett > --- > Documentation/core-api/index.rst | 1 + > Documentation/core-api/maple_tree.rst | 196 + > MAINTAINERS | 12 + > include/linux/maple_tree.h | 673 ++ > include/trace/events/maple_tree.h | 123 + > lib/Kconfig.debug | 9 + > lib/Makefile | 3 +- > lib/maple_tree.c | 6943 +++++++++++++++++ > tools/testing/radix-tree/.gitignore | 2 + > tools/testing/radix-tree/Makefile | 13 +- > tools/testing/radix-tree/generated/autoconf.h | 1 + > tools/testing/radix-tree/linux/maple_tree.h | 7 + > tools/testing/radix-tree/maple.c | 59 + > .../radix-tree/trace/events/maple_tree.h | 3 + > 14 files changed, 8042 insertions(+), 3 deletions(-) > create mode 100644 Documentation/core-api/maple_tree.rst > create mode 100644 include/linux/maple_tree.h > create mode 100644 include/trace/events/maple_tree.h > create mode 100644 lib/maple_tree.c > create mode 100644 tools/testing/radix-tree/linux/maple_tree.h > create mode 100644 tools/testing/radix-tree/maple.c > create mode 100644 tools/testing/radix-tree/trace/events/maple_tree.h ... > +Allocating Nodes > +---------------- > + > +Allocations are usually handled internally to the tree, however if allocations > +need to occur before a write occurs then calling mas_entry_count() will > +allocate the worst-case number of needed nodes to insert the provided number of > +ranges. This also causes the tree to enter mass insertion mode. Once > +insertions are complete calling mas_destroy() on the maple state will free the > +unused allocations. mas_entry_count() has been renamed to mas_expected_entries(). (Note: test code is still using mas_entry_count()). Cheers, Mark