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 10A10C64EC4 for ; Wed, 22 Feb 2023 16:32:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7B1FA6B0074; Wed, 22 Feb 2023 11:32:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7616B6B0075; Wed, 22 Feb 2023 11:32:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 62A266B0078; Wed, 22 Feb 2023 11:32:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 511256B0074 for ; Wed, 22 Feb 2023 11:32:31 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 200FCC0876 for ; Wed, 22 Feb 2023 16:32:31 +0000 (UTC) X-FDA: 80495470902.03.E19B655 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf30.hostedemail.com (Postfix) with ESMTP id 2AC5280013 for ; Wed, 22 Feb 2023 16:32:28 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="F/djVcah"; dmarc=none; spf=none (imf30.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=1677083549; 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=SOMAXJwuOYnxZLUdHf/OeEwA8P1Ab3R3hBjhrroB6DQ=; b=JM6U6sPWpxJTh+NlUDTINmAq4DoqTycn7hZrsZrlhHoQG4EZfsb4Z1b7230LH+qmiWHAVT 0AZDQnOMEfVUauOeQ3uD0gC9bWi79r5sX1ezdNOgKLNwa6/YQn8+AnzBa1elxEX8zkx7f6 R/zX724vyobJPJos6+Px0Bu8XLjcsBQ= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="F/djVcah"; dmarc=none; spf=none (imf30.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=1677083549; a=rsa-sha256; cv=none; b=ENOnncYm43SJ5SylDlyhbOpoHR4QJK43DtzmbBVLiDLosG0w+kIlrJCwI8Nb04uFnJ8Mxv McVQ7Kz3nfwFtm9whjbAvz3g6QPB8Ku7gsfy7VZ2k3nzstO66sdgRrlfRsLn8imMVdM19N KD2KNkewAi/Ed5Yzc4+APZ+kW8Kj7MM= 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=SOMAXJwuOYnxZLUdHf/OeEwA8P1Ab3R3hBjhrroB6DQ=; b=F/djVcahuqYy22dKlFrvTVKlMT YBgXYrjK9IRvmtgHlYcfU8nb/7D9DzLNFitR4kb1YsO/992uxqNJwuzL0k1b4jmwsQD9qO6yxaiNq BUcdHA2F9xzUNy/c/OElaUZqAvZED6crTgUYHVD6ZiJl/qJKbrZa7UOShP3sbfE398i94OXmlz1qP RznFhC8FBMCGxluiy0udPkFnkZbCzfKOJZ0zDJewsOpK/SrX4/3WjfXNY7CAU8bRNbv5rnEZ2u023 CIe4y2z4r209xoFymPFblyHfBM+H8JvjLfWf+MA/VtKYVI2oaHZCETsJm6s+v5ukIe+SCjdbPDIhj lMy+t7kw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pUs2O-00Daaj-Np; Wed, 22 Feb 2023 16:32:12 +0000 Date: Wed, 22 Feb 2023 16:32:12 +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> <91d34e47-10f6-8278-ef4c-72cdfa24e038@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91d34e47-10f6-8278-ef4c-72cdfa24e038@redhat.com> X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 2AC5280013 X-Stat-Signature: t8531feheaso9fzngjfkytgwpxaszyu8 X-HE-Tag: 1677083548-870532 X-HE-Meta: U2FsdGVkX19ZY6JY7FzlluFiIhGeX8llSNUGc1K7wIQiHGvKuGc/sTtAoILjKZRNc9ppQH9nR37pvZeF2YcrTR5HtTKMC3uQywqx81rIFW8U3iGsZ3J09DxuUDlt5b/pu7dmDI79MRjqeAvfNrwAFqSQr/aJbLkVloXdlk9qHfvJBLL4I4YArn06ZYMtDaecwUqgt4l+JnHFFu4hqNTmo9YHQMGXCnQzbKpQ0mgef7Y3K1U/ihsoXy9+vbIcKbl+DLh6I0qj+MqQk0eCN/dKY2UJ6jsVtCQRh/43e5E1rVVLf4rSxRIWMHyt778GQYCaYZMyC/3hkXjS0yvNxdGTT5Us6qSGozCb4CMQMz138TzssnGEztvjtMrqkboWgRyIotViXye19037ENh25VA8W/VtMt9iH3vrbduNL+XuTkhwZjtM8xbsaUdC2v9it+YevFY+ogxFfufxDgVDO0KWoAQcL8fwfZZyifHcLXJAWYeZlWFa7VBrlZjJcVHApkVUhsa3hRhV86yvgCQF3kKMp86wv4vzW2WZ7G16R3cJqtOsEyAwqEp+1FtH2Xy9Muz/VtbX+hHsSXROaavuIGR4hYKBfz5se8enlbYtABMypjqSDiHV7R2iI6FqurnaRoZ55qfT5YHNdeo1lvucLPR9iiaFoMgDCxci6dqRmLnUFt1IBkDq88vYOvMgUmmM02VxIbx3b023UDBm/Yi1ApQLOmDdUr64FSnVMKp80+U5vuECqbI1hy/gPo6fOjFgbQ8KgTzW1fqfpyYSwKTIU8T3sGC2hxI3Vy0TyCbfKAlqq/vgtpus48SbW5kFfW8mWrNyXjhmEkQc6zAzD/7G7SeRwkSPobIl2reLULSAY43k9GENdPAglISjyHSeAp1DLAs1pgoiCUcd9Yfu4RXHZF11ATtasiiwUhI44FgewyHCpSH81/PwYtUBSgai7F7rKG112+WSqZ0lMtNmgTLDc5c X9P4IKwP ExC/n0m+mO67q+BKNOklaQQSrD+yU0cMNXCk8YBSx6UCU96vUT2ymiJXVv8YU9XoyqQItQjmI4xwWYoMmwzJ+DVPnzofwabXAf07tOYbZN0uHig+T2IWoqeGwRjbVahCllb10GOkHdaTvwxa5WOtujd6JHu6f0J7SEO0PRewsaSyzpYLRUJebYOTr97wyws2A0v9NNXQ0vXExE1M= 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, Feb 22, 2023 at 05:11:34PM +0100, Danilo Krummrich wrote: > On 2/21/23 19:31, Matthew Wilcox wrote: > > on tue, feb 21, 2023 at 03:37:49pm +0100, danilo krummrich wrote: > > > It feels a bit weird that I, as a user of the API, would need to lock certain > > > (or all?) mas_*() functions with the internal spinlock in order to protect > > > (future) internal features of the tree, such as the slab cache defragmentation > > > you mentioned. Because from my perspective, as the generic component that tells > > > it's users (the drivers) to take care of locking VA space operations (and hence > > > tree operations) I don't have an own purpose of this internal spinlock, right? > > > > You don't ... but we can't know that. > > Thanks for the clarification. I think I should now know what to for the > GPUVA manager in terms of locking the maple tree in general. > > Though I still have very limited insights on the maple tree I want to share > some further thoughts. > > From what I got so far it really seems to me that it would be better to just > take the internal spinlock for both APIs (normal and advanced) whenever you > need to internally. No. Really, no. The point of the advanced API is that it's a toolbox for doing the operation you want, but isn't a generic enough operation to be part of the normal API. To take an example from the radix tree days, in the page cache, we need to walk a range of the tree, looking for any entries that are marked as DIRTY, clear the DIRTY mark and set the TOWRITE mark. There was a horrendous function called radix_tree_range_tag_if_tagged() which did exactly this. Now look at the implementation of tag_pages_for_writeback(); it's a simple loop over a range with an occasional pause to check whether we need to reschedule. But that means you need to know how to use the toolbox. Some of the tools are dangerous and you can cut yourself on them. > Another plus would probably be maintainability. Once you got quite a few > maple tree users using external locks (either in the sense of calling I don't want maple tree users using external locks. That exists because it was the only reasonable way of converting the VMA tree from the rbtree to the maple tree. I intend to get rid of mt_set_external_lock(). The VMAs are eventually going to be protected by the internal spinlock.