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 749E0C3DA4A for ; Thu, 22 Aug 2024 19:55:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0151C6B00ED; Thu, 22 Aug 2024 15:55:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EDFB66B014D; Thu, 22 Aug 2024 15:55:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D7F696B017D; Thu, 22 Aug 2024 15:55:29 -0400 (EDT) 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 A56226B00ED for ; Thu, 22 Aug 2024 15:55:29 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 5476DA19BE for ; Thu, 22 Aug 2024 19:55:29 +0000 (UTC) X-FDA: 82480935978.28.4C5C164 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf06.hostedemail.com (Postfix) with ESMTP id 2EF11180005 for ; Thu, 22 Aug 2024 19:55:26 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=fbDpoz7B; spf=none (imf06.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=1724356510; 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=Ao10EILDZ2z6IBxtVG/qLyITy/Khz5skvoVpjBv2kTw=; b=5G5DugAyJq2Z78IuLsK1j8VKdSFQQq/owDj8ZzrQwfFhRBr8pRp5CNZr1J//E/0GBYHSyS eK0Wu7OkDWlfWGVOtJuk5lgApOLL7oRtp77s7oQmTVzTXYhub7m3/CURzE4NSSr/S9HsqS VyBjIR2R7WG/9Khrc2NKJ+2vT3DJHB8= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=fbDpoz7B; spf=none (imf06.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=1724356510; a=rsa-sha256; cv=none; b=XQZwR79X7ilN9vgwkci5m0yChLlVtDtQoJk498f7SdqMIhxD7pKza02pWdpdzecMedoUMV i7zkOjXBndeHxeA0OBff788FuhOXqpC0zhJJvav7Py1TARdz1S2e46F0uAYw2PfrD5VyKV 3V9E3MwcLs4P81R6HQXWA6qZpyeuK1I= 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=Ao10EILDZ2z6IBxtVG/qLyITy/Khz5skvoVpjBv2kTw=; b=fbDpoz7BbfRITrrF+RnsJy9m+n VQ5K0wCcXuhZPDQ1zdn78S82ZVCf1k4iVdzxygyMSw9OPhK84Oapu65m6fu2yJholD17hE8LOqddr TgYovE2rSEB0YSHkr/Sw+mg4B2TC83mKu9KG2fIj6Kwu9RHzlA32ImuupH1RctBqtO4MyQWjnPGzW pUl37H8/icImB9A7Bi9njVEQQy4t/9MNJQen+Rcv54+oAxEb4E6YL4TYUGLSddF+rEG6GyaxqIqBV rZD3h1620HAuTYGvW2FrBYckB2W+yf6mTpZCAocOpn27i3SmidgHZQzv4xU+V+uMYDP3H+qZMNbSX JtWFendg==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1shDtx-0000000Asen-0mYL; Thu, 22 Aug 2024 19:55:21 +0000 Date: Thu, 22 Aug 2024 20:55:20 +0100 From: Matthew Wilcox To: Mark Brown Cc: "Liam R. Howlett" , Cristian Ciocaltea , maple-tree@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/5] maple_tree: Allow external locks to be configured with their map Message-ID: References: <20240822-b4-regmap-maple-nolock-v1-0-d5e6dbae3396@kernel.org> <20240822-b4-regmap-maple-nolock-v1-1-d5e6dbae3396@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: ko1h5z7f65juduo4w1obrdxpt1xto9yn X-Rspamd-Queue-Id: 2EF11180005 X-Rspamd-Server: rspam11 X-HE-Tag: 1724356526-230912 X-HE-Meta: U2FsdGVkX1/f+jQgLJLWZ4QTlPEVqd7VkUT3mz0DBiGcRGKO5FbpQzvHmGPcj6pHLqcmWh/0HvFcZxaLAYMvqo1pjFD2ttAFQyCp9ZcvtEoPeudd/pe0k9cXp63fV11tKU4M3h0uoITf5lb2UnTzpA+MkBYYXK8JtQ4aAHL4Xs09KdRQTFnYWCX1VOqh8kud01iuIZVcZ/VFXh3jgKhFtnW2bOBmRJCGkAqpnyiWswBsPGPagRQCgtyBAoYJml0JlenV4QTvvQR+gzLxGt3dxPBgaFVWqimw7/C1LbQfcOp7+WMkzTjWTJ4EXuJ1GxMF6s19XfwqC67QTzuuLFjzyXaeIOuMh387lqa9hc6kbL7nLF7pFSn87Bof/OGsFb8dN0dfwOPSt8ki72s9ml2r+Cglg0l+jFRYZB+iDWTogI32xWtsu715wBFEpjWkwrrS/aD98+bq3N8NZADmn4ZIZ6Axg0aKMQUuNPAKrtriFI4IwYzaBBSqLiK1OO32OPyKB2klWVr/V5mErUvqgMiwrcgBytWirB/jvbUoQeqGj5c5k+I8Nu3DQunC6/F8mE1Fp238fOL5VWIsIroyfczlbpgU1pxsUDnL8hUSREA/PdvFGTqE2AKsYvm4h2ANXT0e96+yHvw9YKvP1eKcAG9r22zJUZ8UBz1U2lZL2mhamxxL7Dd4yQgfDie4DCYbPjnILCYo+EcnlJqFGzo4zn4VOJgoxtx2Ym+a+ckUFAslvhOSYWusFXqhwxg1fvfqyR6XKu9NYLa+3IYaIWDg219zXzCXm8VmbiTeNSV/FvT9nEuUkifEh2WkVS7L2eqt1Lz2CfyfW8X/XDx/ys0AIOrZJetdpk9dNG7qFzvmbBBFeSfMIGfJZEjiR5scP8Qs5tDbsoIPOpgOXwF95Dk3wZ7eywnPmQMxHNX0nmGrxlQT5zUL30+IdGjwYDZ0qaS/L23OCVUdlH17QpwWd70860X YAhmwWHv sa+bjrR4DJ6DVMbtxhz2IdSdEbEw8JuoL2i6AMLT3KurFZCgzO8wtCS6LflMXWmuoS/2fD8AvTqBYgNBP/flgKmNO6sb+HyWLbaXl/pJC3+Ak41Hk2M0+DYYQBXlOalBUqMQgyZEUVo9SRoEi6Fk4E/4NoOObVUEkFoBF8FxyN5FeQsiyYtPi9GG6kFfSaxtoeqanSworhjTmN4wPG1KOQg3m54GPwYidQ06xcwxY1LtgqCFCQZilr1/8ZnjXGkj7AKAW X-Bogosity: Ham, tests=bogofilter, spamicity=0.000102, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Aug 22, 2024 at 08:48:56PM +0100, Mark Brown wrote: > On Thu, Aug 22, 2024 at 08:21:40PM +0100, Matthew Wilcox wrote: > > On Thu, Aug 22, 2024 at 08:13:35PM +0100, Mark Brown wrote: > > > > Currently the maple tree code allows external locks to be configured by > > > passing the lock itself. This is generally helpful and convenient but is > > > No, it's a really bad idea. Stop doing it. Use the internal lock. > > It's a temporary hack we put in and I'm really regretting allowing it. > > I mean, we do use the internal lock here since otherwise lockdep moans > but it's pure overhead which just complicates the code. It's only ever > taken within another lock, meaning it winds up protecting nothing for > these maple trees. We can't go the other way round and use the maple > tree lock as the regmap lock since apart from anything else it's a spin > lock and we need to use a mutex most of the time to support busses that > sleep during I/O. When it's an uncontended spinlock, there's really no overhead. I wish I'd been firmer on that point earlier and prohibited the external lock hack. The point is that the lock protects the tree. If we are ever going to be able to defragment slabs (and I believe this is an ability that Linux must gain), we must be able to go from the object (the maple node) to a lock that will let us reallocate the node. If there's some external lock that protects the tree, we can't possibly do that.