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 B3E85C4332F for ; Thu, 29 Dec 2022 11:33:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B6A668E0002; Thu, 29 Dec 2022 06:33:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B18D08E0001; Thu, 29 Dec 2022 06:33:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E1AC8E0002; Thu, 29 Dec 2022 06:33:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 8F3F18E0001 for ; Thu, 29 Dec 2022 06:33:36 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 67972A0A2E for ; Thu, 29 Dec 2022 11:33:36 +0000 (UTC) X-FDA: 80295133632.20.3534432 Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) by imf07.hostedemail.com (Postfix) with ESMTP id C218E40009 for ; Thu, 29 Dec 2022 11:33:33 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=d65eMAGG; spf=pass (imf07.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.215.172 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672313613; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=qTVxiGDTHL6hg1UtFQZfca+oAw3eSFaWQe0kuo3tP9Q=; b=UwdO0KzJx4jzaHMdkHWzSYhMYS4GBITBVrplO8zPnA0HiKPpf/jg/H4VBaxIA2B7r2hIgC O/x7tNOIiULMN5FEB04D2ZqAla9GhdLrCuYtEB1HKPYynCgmY5RC9g+FdBLs+eMt/SzXsZ vmqFsKnvhAtD2wI3euh1ds+LlcfImJQ= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=d65eMAGG; spf=pass (imf07.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.215.172 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672313613; a=rsa-sha256; cv=none; b=R0rF5g4Esbv+K09yf9eNoO2lPn6K04FtGGxwVesYnHRWEw6aHRCehFQQzKZY82hJWzb99p rmj77B+cbMvt1VF+I5q4CdOdi1Mmyioko4S3whyW+lTxdtdjGBeLDsMY8ugw7HWSoj1eTs CrlxNOeNcJyso1w+vvkjJhx+aEel8zg= Received: by mail-pg1-f172.google.com with SMTP id v3so12225125pgh.4 for ; Thu, 29 Dec 2022 03:33:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=qTVxiGDTHL6hg1UtFQZfca+oAw3eSFaWQe0kuo3tP9Q=; b=d65eMAGGk3tndOjyb0lT2sYt7tsemWRwoQqx4ooPMj0H+EA01kJ15xOPX4X+AmkZa/ x9Jc69lBdrTWFxI1uCuMx7QrRByzMJxs4vkW69MwKe7d6/A7GMVx6JgswuJ/lM+zbQJG aUnWu1GZA+jNg+4USaM37ZlA/MpyZA+69zji0o/pKdvo1rtWlJhcuqco6ZB+96p5P3kK rSt46jw3rfyfiYC0XH1iE5csFT8LSp4zoc62xHezweFq4mk3ZZ1VeaoX5fbZ2OkEm+EM 6/gLo0q3Cy1m2mETPNxJ9CTugIfAPAfTnvz8rwomFWgfek9q7jy/9/ID75afCbZ1nzql /xOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=qTVxiGDTHL6hg1UtFQZfca+oAw3eSFaWQe0kuo3tP9Q=; b=Yj8i17deAtlQ9KGhdHslHxBZ78Tpysu/x6IeZYfsq2U+7sPtB5FwjQV0VZx4c0IPwi yLG+0hkQe8Xx1pzDr2HaA4/uG7Q4hC7FTgVN7G2eHpTZEnIzyPSOaFvisfhG7u6eybYC 8hbxwmaBV34iUaFU9bTTuLN4tPMFSisZLCVClDHcRq9kWGcGyi9cjKMDrV4gSR4/NIQC VzhY1j4+XWF3od2H498PxUYaEF6NQe2fKRuvGhkXXuFQNLbuFIYbtRfeOlaED6g7Ga39 y8H4TS/OSU9Iw7Sr4gIYNPvXS45Lt059NQw93cpjWQAVXYLmE7UBbXqaNvcz37SOXsIW u14w== X-Gm-Message-State: AFqh2kqdmmJ0rNLCn2oBriQX2sxe3U2jiqD8UC4D317vom7ULwt45xwQ 9XmmVSpK9V0L28M2RUTzBBQ= X-Google-Smtp-Source: AMrXdXvnmF6f+NEOc+uLAfGZASLXPlvHzt3wKi9SEnxPBOt39NwwQbkr3lgpYgOEiMhDZKciV49qIg== X-Received: by 2002:a62:4e93:0:b0:57f:ef11:acf9 with SMTP id c141-20020a624e93000000b0057fef11acf9mr27300836pfb.10.1672313612386; Thu, 29 Dec 2022 03:33:32 -0800 (PST) Received: from hyeyoo ([114.29.91.56]) by smtp.gmail.com with ESMTPSA id d188-20020a6236c5000000b0057a9b146592sm11871081pfa.186.2022.12.29.03.33.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Dec 2022 03:33:31 -0800 (PST) Date: Thu, 29 Dec 2022 20:33:26 +0900 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Suren Baghdasaryan 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 Subject: Re: [QUESTION] about the maple tree and current status of mmap_lock scalability Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: C218E40009 X-Stat-Signature: ox85fi5y6go3s7aoy14ktrcoa6paxcwd X-Rspam-User: X-HE-Tag: 1672313613-46068 X-HE-Meta: U2FsdGVkX1/eU5TQwpEskYmKmR9w9uvsTFE0l8YawNk1ZZ9z45B9ra5FxEIS1fSYjKxl1P5fknMljdomYSbjrMUuxX41AsutQHWwm3NYVSZj8JtAbQnM2FpyMRee+ipKifkDC4zRWdumjUwFhPq2/suuZOdO3Hj3nW+gcKx9w9b7KgwJDMdjAmW1qFYWr2uZSXfwghQ6kFJvvkvzI9UmLC3tQzsVilz4JCmzBxe14b0fKacrW460xKWrH6JthcLbuYw73NS9kMzM207u+Ziydf2h4FQT45V27+fl6/y597h9XdLj0cLKrjPxJB90QNqr88BNP/DjaJnuxb2c7JXPohn9bbqMiH3rem1dt4jv7YYdeRo+9Rx9t85f168TO0K7q67jcO0GV2b0l9KcBiZlqx36Uc3cLZUvBfgHiLrE91sXMV6wde1w3RcYiVS8FfiQ1sLOJgHI8k8VtGIDFg8TUjLGBCLDjGe5m7onHj5pUFgbeWjeCQ2JH+mM48LxGECC/cEh+7uah+xcvCXPoE4xtGo+QI6IaMJrITzlNSAh11aeNlS2bFSvF2lX6Eo8fDdH2M9EALlAyDnlY8XRRvQAW5J2fXjePB+kRdYEC9AMIG4dJKVq9/TlW1mIKoMbHH5XIQHn8qUNv44eF523vBZNdgHHnSkgkDaQt33TxDB+ukXQENqAOGdAeQ7+fLuEvqF7RSWoam4xntNrRajY6+Gi0WElwxQ4GstHNyzqEiA9W1YOZ/WZw+u6wqTmyakaHL+PF9t3YZ6trm6NfpiBRsxZLm3sjX/YTeD7qG974gQHXF1WFKs2LyLXR3VSmfWIqQfCXlBYsxX2tQKneXx36a9i7o+IR3Dzjbm7OJ9KtC+hvn7WanJ2JGy6Hc+VRKexMoOlgjk1UXzVGTCt2XIcOgZJeCUfbKN/mBn/XuSfAExZPNRt2up/M5mGf0+PBIsMWclfmRpKlKutuRQ+vwa69m0 ArdFzzA4 bm5dnFBjihXxdIwmI6x+4akTZr2r9rbTsAP0CfPx54S+QMg7fl9h7/NIkc6lIySBi/3/LcchLZEYrE3k3P3Y3+pMO2MWtGLmr8k6M92JgppuGZ+Cl9qIqPFUREtsz8cOI3hdKW3yOwRK9IJPBDAy3B5z4FyrB5la+cUepZZ02+IVhJUI= 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, Dec 28, 2022 at 09:10:20AM -0800, Suren Baghdasaryan wrote: > 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. Thank you for the link. I didn't realize how far the discussion had progressed. Let me check if I understand correctly: To allow non-overlapping page faults while writers are performing VMA operations, per-VMA locking moves from the mmap_lock to the VMA lock on the reader side during page fault. While maple tree traversal is done without locking, readers must take VMA lock in read mode within RCU read section (or retry taking mmap_lock if failed) to process page fault. This ensures that readers are not racing with writers for access to the same VMA. Am I getting it right? > 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. Looking forward to that, thank you for working on this. -- Thanks, Hyeonggon