Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp4839005rwl; Wed, 28 Dec 2022 09:28:11 -0800 (PST) X-Google-Smtp-Source: AMrXdXuFChyqASjxJ11gcIYLE7VUx4WLw8cNNtYzUF5TsU1aRp3HHM8Vx/H5zbElk4AJj1sA5w3P X-Received: by 2002:a17:902:f2ca:b0:189:86cd:d7c0 with SMTP id h10-20020a170902f2ca00b0018986cdd7c0mr33570720plc.18.1672248491672; Wed, 28 Dec 2022 09:28:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672248491; cv=none; d=google.com; s=arc-20160816; b=q2O0HTX1uGAOtdfautZ05qN3M1vfksmxvgi5rAr+veRAKUPC7omxo1LjRfqMlNdNAk XT9WbSE6Lb8UuC0axb8i5tLjw8sOr6SQ3p4rP+z1IiFlKYREBpF50zf1WGjCB/KHRj0r bqF+y6NxCVNttqtyktKMXMQQp1oW4FYuhMB0nyzrA80/R7GzY3cM4Oi4V1z140jeArkz kGuABlJCFPwJ26OcVW+0AtZRssFHh6xLFCcqvj5QYR+QXmsfHNA5EwMU8tvIwSsonTQj Glt8yXr6KkUt0M+OgKyAYootTsDe8MwhGIqMgF1W6vlYYXjIuqH5o47hO3GkPag1jleK j5AA== 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=oYsqnZ8FJ65xaJlOCHcTfd528vZbbXtntY5OMB92i10=; b=c9qeLqF+N9OXqEsXmUS9c+UJmTucbNrFHw2Zk6BJnMre+Gih9ouyQdJOSdkGeCsqO0 NkBwFGnjatqCKSCtTqgV0I8UDXPN5XUHjxvns+Pl5OoPrxKl9Mm2/EyQ1qFd7N8BwDEX lt+VOQkLejKCZbzgKxKGnmuiJK42rEC/gKCfcHA/8yyoN5wCHqbg3qY7fEdhWcTff2Dm Dyo2HHfvSewt7sH+Nm7pzxqw90b4X/u2i8ch4fKeJ43hkdgyQRKg1zP9UleVdu8AwE4i sfOhezijesCGVJCcCpUsYQYFmxxBQxxdEDnNLmU1Ji6wJfgpnOnBjLUaUMOplwTUzSx1 mj2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=UkbVoEG8; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w21-20020a1709029a9500b0017ef8bf8a91si5751122plp.439.2022.12.28.09.28.03; Wed, 28 Dec 2022 09:28: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=@google.com header.s=20210112 header.b=UkbVoEG8; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234248AbiL1RKg (ORCPT + 63 others); Wed, 28 Dec 2022 12:10:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60768 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233281AbiL1RKc (ORCPT ); Wed, 28 Dec 2022 12:10:32 -0500 Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com [IPv6:2607:f8b0:4864:20::1131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A829F1A6 for ; Wed, 28 Dec 2022 09:10:31 -0800 (PST) Received: by mail-yw1-x1131.google.com with SMTP id 00721157ae682-47fc4e98550so87249977b3.13 for ; Wed, 28 Dec 2022 09:10:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=oYsqnZ8FJ65xaJlOCHcTfd528vZbbXtntY5OMB92i10=; b=UkbVoEG8EXDv03CU0ZLBkw9xvwi0gUbu6WtMl0/cSzlfr+HMnEoXWh9otr4CKs9Z5c atkhIsOItvBZKXOFzukIjmG6UfPDzKOLfYFLaFznsoXUsFpLdrbpXxDYygAfihpc+4Dq Ndu6c8nz2L5bcq+UhdEY+T8o4G/wAD8HnBjKmkx86AIZCsfCjrPcCMuorp/pP9jghs8k XixkENiqi6u9SIG3RFGPBKdIfgdy8FDxBbGKAY+OgI8e4BYXGrt6cB6+DRjFBvUnLTyK BHtSjt7JzK2d1dYz6w21gB7Tf4P6hL5jo5wrTZbG3/rnZSAnEpXX55QM6cxuRKlg9QGs 3MtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=oYsqnZ8FJ65xaJlOCHcTfd528vZbbXtntY5OMB92i10=; b=wjSZ2t2oHaOnSHkOpImzxKo27Ikv4PzxI5Y4dWwtkqNpbarGLM/sFhyCC9JW3z7iMw vwauNrOY/fADjLmR2gEGBWO59vFsAh4VkJBZW2rorUdUmOhJJFNgGZ28ZAtQl7JkPauG jLiDnGFVMKuE/LUR7PLYJF+GvIssynL8VfP/NHr9evottGp2Cxmv4zvkNG9gXjcYWT7A Hp5ZzjWD59EsPNMxqROrIcJfhlqSCaWkNIntw5xHYX/+/DFIq+QMhBZx/BdtGagVD7Xg RC5zSGTwbk34ffsJ2cNJGmZHuAbiCaTzlWDS92ntO4Sf4n+6go6B90GvbNftwNTeHzVC 6f8g== X-Gm-Message-State: AFqh2krtGnVIG6B5u+gbfEl8XsljDPrvWaGWyMcFAVs/Vlrril7RIKSd rIkXaBdCGyRPKIS7hiaLBUosxb3iSDchVJryzqC6xQ== X-Received: by 2002:a0d:d611:0:b0:479:b6a1:d9a4 with SMTP id y17-20020a0dd611000000b00479b6a1d9a4mr1119032ywd.263.1672247430626; Wed, 28 Dec 2022 09:10:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Suren Baghdasaryan Date: Wed, 28 Dec 2022 09:10:20 -0800 Message-ID: Subject: Re: [QUESTION] about the maple tree and current status of mmap_lock scalability To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: linux-mm@kvack.org, liam.howlett@oracle.com, willy@infradead.org, ldufour@linux.ibm.com, michel@lespinasse.org, vbabka@suse.cz, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-15.9 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, URI_DOTEDU,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Hyeonggon, On Wed, Dec 28, 2022 at 4:49 AM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote: > > Hello mm folks, > > I have a few questions about the current status of mmap_lock scalability. > > ============================================================= > What is currently causing the kernel to use mmap_lock to protect the maple tree? > ============================================================= > > I understand that the long-term goal is to remove the need for mmap_lock in readers > while traversing the maple tree, using techniques such as RCU or SPF. > What is the biggest obstacle preventing this from being achieved at this time? Maple tree has an RCU mode which does not need mmap_lock for traversal. Liam and I were testing it recently and Liam fixed a number of issues to enable it. It seems stable now and the fixes are incorporated into the "per-vma locks" patchset which I prepared in this branch: https://github.com/surenbaghdasaryan/linux/tree/per_vma_lock. I haven't posted this patchset upstream yet but it's pretty much ready to go. I'm planning to post it in early January. Thanks, Suren. > > ================================================== > How does the maple tree provide RCU-safe manipulation of VMAs? > ================================================== > > Is it similar to the approach suggested in the RCUVM paper (replacing the original > root node with a new root node that shares most of its nodes and deferring > the freeing of stale nodes using RCU)? > > I'm having difficulty understanding the design of the maple tree in this regard. > > [RCUVM paper] https://pdos.csail.mit.edu/papers/rcuvm:asplos12.pdf > > Thank you for your time. > > --- > Hyeonggon