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 70A4CC4332F for ; Thu, 29 Dec 2022 17:31:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C12978E0002; Thu, 29 Dec 2022 12:31:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BC2AA8E0001; Thu, 29 Dec 2022 12:31:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB2338E0002; Thu, 29 Dec 2022 12:31:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9D8988E0001 for ; Thu, 29 Dec 2022 12:31:14 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 61692AAF12 for ; Thu, 29 Dec 2022 17:31:14 +0000 (UTC) X-FDA: 80296034868.21.12DC3B7 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf29.hostedemail.com (Postfix) with ESMTP id 780DB12001C for ; Thu, 29 Dec 2022 17:31:12 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=fZJ91ZHH; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672335072; 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=O6Ikrs1CIxHfi8Ue6kwk76aDhiVwW97NYJ5AhQiikWY=; b=QJzkRRGUoS41dAox+hofdikxFPUtz59ThwseDE5PRiBeaUiirYbAnpBVhsjHbdFTxqicyi 9kMUQn5AFOtRzXGEYKMxrLV5ITrV5yHcKMamKJj7doP+017MDj0bzQQmMrvEnwJxEfFDp1 ttZcgPl5N1HPZGkXY8M2Dhj4GufPmxk= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=fZJ91ZHH; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672335072; a=rsa-sha256; cv=none; b=xDc7CLVMjKFVOgakWM4EWp9JBOvK0AD83azpAf4W+duBYUGD62YXodpfTj5Y2wnuNNHW2g 4sgwFI3Y8GRXMVim5MbTsGbMXa1iEl9MlYEK/QcEdJMjP88cziW50HMiOEQZIJ815D/jhy nyixr2eTru0Zj3SJkI31/1JNbTh2gxU= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=O6Ikrs1CIxHfi8Ue6kwk76aDhiVwW97NYJ5AhQiikWY=; b=fZJ91ZHH4wjOdmJFKpknmM2JjI ls0n0/1hxa4PVs+RaxBEjxjrk4pI42FWPiAnjtNaKauJuvjhv3Xa7M+buiGTIYLkoF9QItIdP+N3R +Qqb3MWEu6NwN5QK8kLvrU0VRZd+T4/Yzu5S1NaHPEYCmplvs7+Vc4wuiLTGrtmTJy5SXLINYPOBt muE8v74cPqxViZwA0t/J9AL3MJk11Kqp06oNSbfHirv8WqJKupT2QEZ6SSx7hFJuEm825pwiZKVtF rnzyceNMthtUK9ir1LVYqnvCak6NLRNGKOLk5tRutpVoWpmWsvprSRQoFafG66UwygxMa/CBlq8Ny h/Wo9xSw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pAwkN-00A11E-Ng; Thu, 29 Dec 2022 17:31:15 +0000 Date: Thu, 29 Dec 2022 17:31:15 +0000 From: Matthew Wilcox To: Lorenzo Stoakes Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, liam.howlett@oracle.com, surenb@google.com, 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-Queue-Id: 780DB12001C X-Stat-Signature: 8sgou4c9ejec7pztnmpye5kho53xmndz X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1672335072-30206 X-HE-Meta: U2FsdGVkX19kWAmYtsMwYWViHoYE7KjiTRbuISRM5LYYUl3g77yf4qd2kv9QuqqgmmELF9sPXi0TsgVBZSpxxt4mXTIziTTQgMy6WwwmM3s0bvXRQ2HWZq6OVqnEbNaz5u0O7X4bmFS+UpF0OFctvL0Y/nnjGbLMmrdPOTxqhp9p+jAvcbXfUgz3F518/CsvEs/joX5JF2+rPla3koVsaqJai09VOeiSjoXPjHIfrtDALjbtokLURyCQJu9OttP2iyCbDmWiyCX7FRpLKfd/wlOqqh0xih5FkaiLskUpctUwxTgv3npIql2rPomU8hq02sQGY5yU71tdNk3jyfq9BvJ6Ruv4CqMMWjtKaLQHYWItmrlQ3bPi0vvvmJlRFgVCArgY31XtATh80KWGRjot5XD4ngI3pCYSwy3KfaRvy3eFMzqnYxOD6tPryUBpIPmSzb/cv92idfkCTwmuZE1oFgw5GDWx2j3TUziRrvd64FAcyF30MQZVbkF2jAk2KODUJ7WYFsjLFXQtzAdeZRk7wRnIqYLOwOcYIOCQkGsthh9cArfgn5jaU5aDul4brTDkDAN09V1lREzJbj9tgg+e+SBaAaL+0YFq+ED4KKRcY4BkngfFX2AapwEVvRcYBmlj9o35XWvjiJJX0mFOHJkGawkjkGSsXovh2UTjiuq+ybwLjQ7hNcs8N/TnJDQdHAdEXqzLdLQDzwgZGaNqjHLAPQ66tufnO7l+W/q12FOXa+3qdv66epiXW3iLgF5IZD0YM5VEc5V4k3Et1/92IHhVP2T8k6xBqxl95WBzMNMB3e8nLcmAYPs39zPhos/2BXoPe4eRbkuYz4OuGodTwy+efTtgKUJR4nSHoEv5dhEV3aJ6znFRTQMDogUYjM6KureZw83yWNGLa1u7WbGfZWs7Y57F6d3F5537IrzrCr6k+Tgwfz4KIwL++jmO5xHmQFBoqnFr5JVGYsPOwwUdb4K 8Lg== 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 Thu, Dec 29, 2022 at 05:10:28PM +0000, Lorenzo Stoakes wrote: > On Thu, Dec 29, 2022 at 04:51:37PM +0000, Matthew Wilcox wrote: > > The mmap_lock is taken for many, many things. [snip] > > I am currently describing the use of this lock (for 6.0) in the book and it is > striking just how broadly it's used. I'm diagramming it out for 'core' users, > i.e. non-driver and non-some other things, but even constraining that leaves a > HUGE number of users. I fear this would be overwhelming. I don't think anybody would disagree that the mmap_lock needs to be split up like the BKL was, but we didn't do that by diagramming it out. Instead, we introduced new smaller locks that protected much better-defined things until eventually we were able to kill the BKL entirely. That's what I'm trying to do here -- there is one well-defined thing that the maple tree lock will protect, and that's the structure of the maple tree. It doesn't protect the data pointed to by the pointers stored in the tree, just the maple tree itself. > I've also documented the 'unexpected' uses of the > page_table_lock, which seems to have been significantly improved over time but > still a few cases remain! Now, I think this is useful. There's probably few enough abuses of the PTL that my brain can wrap itself around which ones are legitimate and then deal with the inappropriate ones. > Am happy to give you (+ anybody else on MAINTAINERS list) an early copy of the > relevant bit (once I've finished the diagrams anyway) if that'd be helpful! I'm definitely interested in the PTL. Thank you for the offer! > Now if you guys could stop obsoleting my work that'd be great ;) Never! How else will you get interest in the Second Edition Covering Linux 7.0? ;-)