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 56206C64ED9 for ; Mon, 20 Feb 2023 20:33:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D71046B0075; Mon, 20 Feb 2023 15:33:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CFA1C6B0078; Mon, 20 Feb 2023 15:33:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B9A826B007B; Mon, 20 Feb 2023 15:33:53 -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 A57636B0075 for ; Mon, 20 Feb 2023 15:33:53 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 755061A02F2 for ; Mon, 20 Feb 2023 20:33:53 +0000 (UTC) X-FDA: 80488821546.05.F783152 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf17.hostedemail.com (Postfix) with ESMTP id 698E44001A for ; Mon, 20 Feb 2023 20:33:51 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=mYmoJ0rb; spf=none (imf17.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=1676925231; 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=X6oKYpBwCPPA2hKDvH6wktIKJITLyPmX0fi+XHJg5NA=; b=CPdmyz8KBEwMnkrvqvSe9l60gJ47ES0wOEjKFS/UGTVvL1TStfeE7CrfvIOM+Qk1AHg99y /XB7mCo5EsZtxcPM7hHXk8cHudu2c8RVjjTQsBu8pUDwXVboS2i1jfZwarcmpxWkH/7g/X Xl+MmSvL6x+4DpT3Q4erH3Dkb7mqflU= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=mYmoJ0rb; spf=none (imf17.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=1676925231; a=rsa-sha256; cv=none; b=bUQfan/b/EPSOqzJYA/32rDUtMREy5xgu/yvaQn6GktN9YPAISzjdmUbzEpDIMu9Wpbgzo LPTYSsgYmCe0cIqbspfypG8hLTNy94o/lmYILnqWJViGkKUcz5d3IYBedIYvb8uAPaeygY L2xt/Ml6NHlJ+dBsLLzFtS5JR/aTD8I= 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=X6oKYpBwCPPA2hKDvH6wktIKJITLyPmX0fi+XHJg5NA=; b=mYmoJ0rbUaT5FaaxuvwwJb3Ehe APso/ZhX3utDjjf8833KEVujc3ZRAlkvVNcEp3kq/Vke+H2z+mGGIH9KFor5MOJpidNYY+92Fp3jD SqGAstCH6lAUYqyhaBp8ZUZIkOwlmOiXgQwrVyiDTGYm51xTZN/0jmooRF+bg0ifoTLCvgzjNVief guN5FOAhbkmXODvTRPGzDv8BxOJtg7DZyewqvGsvkvLS/j3unzSdzMH1WR3gns1TGGZhnmkZNJ+0b NbgHzIBLoKGJQ8Jd5bSoPdGixKvBijeQemjCLBIpx6nThFLb774j9BxAbb/06H3VZVtoNiRpTQwaV 1Aep9b8g==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pUCqt-00C0Dm-D9; Mon, 20 Feb 2023 20:33:35 +0000 Date: Mon, 20 Feb 2023 20:33:35 +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: X-Rspamd-Queue-Id: 698E44001A X-Stat-Signature: corj1ixprhc8ut3czow3dygkk9841y8a X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1676925231-531224 X-HE-Meta: U2FsdGVkX1/flZuaQuhiKMoxvY0ESvDD33pGfgeJ9GlqOiv+tLsOR+e+wbK58HR9XZxelkpNPaWu2JZyEK2GWVQW7NUftWLveryheF1KrkqfIfcjb4ySeSYbc9g4mi7/pmKl727YhGltosVcAQSccHgxoRd/rKHE4uMQ8xoni8dD4SB7oKnf0n1cRmc6dXIJuYtSfDGvy17pWG1+/rFJ2xYk4pRQ8PgkJW2J++zSQFW0hQ02XUuFjhwvDENBP4gjkJJztoF21BBTj6RDtvTR8svJJHGa875Z9zVFrtZMX7UPdHLnvVjrA6HB6FPw1Tjo9oOyPZyPnCCujPk5F3TUE75fNY2sbJ3axmvPNQYITo76QczTWr8JUV7oyCnuZOCvwpbxeuKbcOxj23/AkvLuYA2B/RJBuf+gRZtkBB9CFS+PHa54ZkYm7rt+GURy2PimNP72o5QjwCtW6xcj2I7XYKlhqhr4JdAPSXuFq5KLueK2hwtu7nnWBTMASmGD1TF34MASlv2JqXeO6Z/6OCsla7msXOB6fnZADZLYTH8oDHggspQWT2/rlfGfbXICUQQx2aoQuqehmDe9K9wfkTz9nCpqERLifXRRqI8jQJjemp7TgXb3m/POAVOjs1yQceG8wwDfDbRcK1j6u/74Hw8GK2KzyGAj9fWa1yfMcl1EU2UvJ39Axq39CD+4WJtrQRPQKaK54co1szAYgfukbzXuqm7tsWWwJ6GW2P1Od8zHziZFVkpNAgO+Ewa/Eo5IRjqquB5fiAvt6hRwE4vCU/P634o39WGj689juU3qhSqRZCGAqDnlMI+Nd3oLdRJqnHbqji60MQwhQ5AgIRrxOAJ+9bX5T9WexlSXtIJxmbyJ2+1t9uDoNGDCxtJpbBDC5YAH6UC1wdcIzaSRfRx8ZPkt8lSRLPU19re7L7HDhJhoIuvEF/bJ4TrWc/+CZ+wE3UKaoGK2yF9g3SX33ZvEWVc 2FlngMUu /CzsdfxACuCNoc1J2F2hCHc9jxE21pNjN87cRFcmJL9iULdwmEaAEmgmkDu2VZ09e7+IhOvJdSLhE9IcnOCiIj8OOYIksNnWivts3wWnNt280dQpzWtBpnchYSM+ngwUoVPLhJkDWNZs0HVmD7k9ol3DFK9aMOzcAXVveHXfDTv3w+ZwgTVFn34ESTD6KH8vcMrUVsE0vLcWduw4= 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 06:06:03PM +0100, Danilo Krummrich wrote: > On 2/20/23 16:10, Matthew Wilcox wrote: > > 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. > > I think as for the users of the GPUVA manager we'd have two cases: > > 1) Accesses to the manager (and hence the tree) are serialized, no lock > needed. > > 2) Multiple operations on the tree must be locked in order to make them > appear atomic. Could you give an example here of what you'd like to do? Ideally something complicated so I don't say "Oh, you can just do this" when there's a more complex example for which "this" won't work. I'm sure that's embedded somewhere in the next 20-odd patches, but it's probably quicker for you to describe in terms of tree operations that have to appear atomic than for me to try to figure it out. > In either case the embedded spinlock wouldn't be useful, we'd either need an > external lock or no lock at all. > > If there are any internal reasons why specific tree operations must be > mutually excluded (such as those you explain below), wouldn't it make more > sense to always have the internal lock and, optionally, allow users to > specify an external lock additionally? So the way this works for the XArray, which is a little older than the Maple tree, is that we always use the internal spinlock for modifications (possibly BH or IRQ safe), and if someone wants to use an external mutex to make some callers atomic with respect to each other, they're free to do so. In that case, the XArray doesn't check the user's external locking at all, because it really can't know. I'd advise taking that approach; if there's really no way to use the internal spinlock to make your complicated updates appear atomic then just let the maple tree use its internal spinlock, and you can also use your external mutex however you like.