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 5BB3FC636CC for ; Mon, 20 Feb 2023 15:10:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D2BDA6B0073; Mon, 20 Feb 2023 10:10:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CDBC16B0074; Mon, 20 Feb 2023 10:10:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BF1056B0075; Mon, 20 Feb 2023 10:10:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B31EC6B0073 for ; Mon, 20 Feb 2023 10:10:50 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 876371405AA for ; Mon, 20 Feb 2023 15:10:50 +0000 (UTC) X-FDA: 80488007460.22.00EFAFA Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf27.hostedemail.com (Postfix) with ESMTP id CB63840008 for ; Mon, 20 Feb 2023 15:10:47 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=fHlB0hMu; dmarc=none; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676905848; 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=R45rWVDfeg/NXvIZZQJXvpN6fKHMsg4sVZQNWSB6afw=; b=EPr+eOan/K6PPpLwPFz6JZMkm+XWRZGxKG0kqum2C1e8AhmAL3kcoJRD5NiXt+ehcHz0+K YV3NKlNnP3Tph2ZeAHGoAEfR/FqxkWDBcT/ufRLZpR2H37BnxEQy7H5OJtNVo6vh+ob/vc uqXLG57StJN2lvOLY/8hDb2Bogpa75g= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=fHlB0hMu; dmarc=none; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676905848; a=rsa-sha256; cv=none; b=uYV9i2Vt4H27PhdAoSMAc3evhXOVXlKKuzq/c2I2QAgORlwE9HEkxyYTfFeuzX+UjFII9q 7lq12vFk2otuLTUDd0ENQx3dDKYbzytfc8UjbFjC9+uXXxIjeKs/kFt461PEKRIgbIxEFX GDckCtjtgwRpTGMEjuDuYGrCubUgp/k= 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=R45rWVDfeg/NXvIZZQJXvpN6fKHMsg4sVZQNWSB6afw=; b=fHlB0hMuyDt761o7r7F3Cu95v/ WEGj8cgCOqkhOwtPqJX9Jn2aS/ny+0AEsv2qKCTCup+n6nqlxSESxS42BSUB47NMj+HADdfGyvrgS r6jamhtkfYxE+MFTAhvOsV0h3/Wnn+IRgBvovAZQWN7dHzEzcmRdZoeH9K/nPlLFsB7osuFh4nRQD Vs2gcZ/BGbQlsYCmj+6p/x5fXnF0FVlDwKyAF3S//MMqkxbhVrIrNQxWZahYTSZwKdeLNM8GY0zLc 6B/9XksckKXyDHzHeoyZ0f0NDDVyInks4a+yI3xYDI5lKQMQBBn4hzBFHVD/oqHDPBZABN4AFTrkg 9nKzCr1g==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pU7oA-00BoaW-Kl; Mon, 20 Feb 2023 15:10:27 +0000 Date: Mon, 20 Feb 2023 15:10:26 +0000 From: Matthew Wilcox To: Danilo Krummrich Cc: matthew.brost@intel.com, dri-devel@lists.freedesktop.org, corbet@lwn.net, nouveau@lists.freedesktop.org, ogabbay@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, boris.brezillon@collabora.com, bskeggs@redhat.com, tzimmermann@suse.de, Liam.Howlett@oracle.com, bagasdotme@gmail.com, christian.koenig@amd.com, jason@jlekstrand.net Subject: Re: [PATCH drm-next v2 04/16] maple_tree: add flag MT_FLAGS_LOCK_NONE Message-ID: References: <20230217134422.14116-1-dakr@redhat.com> <20230217134422.14116-5-dakr@redhat.com> <3bb02ec3-4d19-9135-cabc-26ed210f7396@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3bb02ec3-4d19-9135-cabc-26ed210f7396@redhat.com> X-Rspamd-Queue-Id: CB63840008 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: qgak44dd4jyw9bw86nz39s3d11j5qgdn X-HE-Tag: 1676905847-536843 X-HE-Meta: U2FsdGVkX199Hukpyhv2lNIFKGkFlmvpHXhhkWuE/lrjSdN+lf00YS4upjOoqtwLbT61VAaOeLNLUMBrX9btbPhJ6983QRWNssdKK0yYxhrEqXMKNGQYNNfynKOrVUsAlICTfR2+xJE8Uj3tq9LrNTMI9twqGihBbsFH7qnZV/p86FyhystKDQ5/wHIenUARCwlcEKvD0kwY7atKS/RIjAXTRPXR1qP3EW8eKSLFqGlRspTVsjRP0xZMjA8v4gNR9zNKkg7uMV6jORSqxbI5Pf1INO4vIT0CNvMtyCJu6V28FazEgLChTZ1LlZx403sy5K5lJZVyWrjrGju/D0RzaklGP63kb9d8/QFPhzhyxANleOY5M80NpTgXfF8VdZaMt2FqRwS0X8rmmX8zi6QfnoPy4w7WIO8rhoum8LSeGGCxnd3o7592/cAph+trfo+GjPntwfcGLjOfgkIBp1b2St7gU6QBUk1swgB5+AyOR1pGxcWuTFD+z2GLtMAEw9EvmACt/vpPWzbenttvcd41NU5Ie2xj3AuuoPyOalUozrPu2XXoy+VPn02THHf6/3XT11n9R2zFoWY4R+vSlmynlQrSOyZ+qP+hMHaO89Ce85W+VguqnDb/tDERFFyTj12H9KDhtZA6mQxGc3DNLpNJln64fU2CfAnXwxcR7C3OH9W8bFV7ZojrfArShzHkxAUDpGOTUkEFvXDFdmhUVpv+hxy0S7bUqUrR05zLa2qRYiGc64+7NtsB/Z/5CLUu9jX8lPbC4NHBtKEEIWC2X66bRytMTjbgVvLCBA0xfcYa+971cFqaKNO7iRA4xa428JsLoi1uYj6BwvUYEoEn5yjAc5bCCAeMWGhBGdmEtAFwwdgaW/bGpkWXdeW0hg50jvsRRGdJn9NCfkjlolxKuSyGODiT6CPs9TFb2abQ0e3ro0J2wlZAnnV769eXv8t7iq2DRhxmLxFlg3gbrXHQlsv P8u/0G34 b59iTi6/uO6xB0F/Ug/YJ7xPmWMFIKryqLrDUS5X/t8ayIdC8qdvWfTmyzO5KO2Y8pbc9ImtEqYZSMEtJ/mdgr+qJh7M4V52F6Di6E/fKb+zBJ+zmmE9SmQQIr6kXGC1wGSAJSoPI5f7xxyMamqpBXPt3uRpOI1UJvBZa 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 Mon, Feb 20, 2023 at 03:00:59PM +0100, Danilo Krummrich wrote: > On 2/17/23 20:38, Matthew Wilcox wrote: > > On Fri, Feb 17, 2023 at 02:44:10PM +0100, Danilo Krummrich wrote: > > > Generic components making use of the maple tree (such as the > > > DRM GPUVA Manager) delegate the responsibility of ensuring mutual > > > exclusion to their users. > > > > > > While such components could inherit the concept of an external lock, > > > some users might just serialize the access to the component and hence to > > > the internal maple tree. > > > > > > In order to allow such use cases, add a new flag MT_FLAGS_LOCK_NONE to > > > indicate not to do any internal lockdep checks. > > > > I'm really against this change. > > > > First, we really should check that users have their locking right. > > It's bitten us so many times when they get it wrong. > > In case of the DRM GPUVA manager, some users might serialize the access to > the GPUVA manager and hence to it's maple tree instances, e.g. through the > drm_gpu_scheduler. In such a case ensuring to hold a lock would be a bit > pointless and I wouldn't really know how to "sell" this to potential users > of the GPUVA manager. This is why we like people to use the spinlock embedded in the tree. There's nothing for the user to care about. If the access really is serialised, acquiring/releasing the uncontended spinlock is a minimal cost compared to all the other things that will happen while modifying the tree. > > Second, having a lock allows us to defragment the slab cache. The > > patches to do that haven't gone anywhere recently, but if we drop the > > requirement now, we'll never be able to compact ranges of memory that > > have slabs allocated to them. > > > > Not sure if I get that, do you mind explaining a bit how this would affect > other users of the maple tree, such as my use case, the GPUVA manager? When we want to free a slab in order to defragment memory, we need to relocate all the objects allocated within that slab. To do that for the maple tree node cache, for each node in this particular slab, we'll need to walk up to the top of the tree and lock it. We can then allocate a new node from a different slab, change the parent to point to the new node and drop the lock. After an RCU delay, we can free the slab and create a larger contiguous block of memory. As I said, this is somewhat hypothetical in that there's no current code in the tree to reclaim slabs when we're trying to defragment memory. And that's because it's hard to do. The XArray and maple tree were designed to make it possible for their slabs.