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 DB9B1C61DA4 for ; Wed, 22 Feb 2023 17:28:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5FED96B0072; Wed, 22 Feb 2023 12:28:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5AE676B0073; Wed, 22 Feb 2023 12:28:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 44FEF6B007D; Wed, 22 Feb 2023 12:28:38 -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 35CDB6B0072 for ; Wed, 22 Feb 2023 12:28:38 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id E1C63A0C6B for ; Wed, 22 Feb 2023 17:28:37 +0000 (UTC) X-FDA: 80495612274.09.4140C8A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf16.hostedemail.com (Postfix) with ESMTP id A7CCE180016 for ; Wed, 22 Feb 2023 17:28:35 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SVEoTXaq; spf=pass (imf16.hostedemail.com: domain of dakr@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dakr@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677086915; a=rsa-sha256; cv=none; b=OQSI2kaSuNfranlEi/y/5guo3cBt784rg7V2Ow+uJekhu4fgrL1ccLCacuYjxLFwxM7dZt o30ttM4OAK+CY++U5IEYOgMiLFkNR3V/foqMqBCLdFHUxGki9CU++lpeBi0x4ZZyqJYk+k QQjIzBHRt02RzomHVARnqwMw2kyxcWg= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SVEoTXaq; spf=pass (imf16.hostedemail.com: domain of dakr@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dakr@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677086915; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=lQEMvrvrwWUFc87bAMj47uqR0LzAryMK3MqNTl4bkt8=; b=1dcHJt4bggDFDdKFxPxQSRSzZtbrmzXewu/q7+5FBoUTod+B/D6Nxk2NXxSEVZG2KVZ3PI UEYpT3C23TYWMQbcmSw24qDBoPSPVlSD8h5sYOGwcRGopGr44+3bEjYgaGl9L09EiL3Z2F 0ZXMyoVgS93IleVM018MGjoN4Iald/s= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677086915; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lQEMvrvrwWUFc87bAMj47uqR0LzAryMK3MqNTl4bkt8=; b=SVEoTXaqSb1deJBae1mZuR96cIntaS3bvX8YAzUgOiJIZCZsuelngurtKp4rA62gDRm/qT h6L+awSlW1AqRAcjCr3DR5sFXpj8jjS5OvLzEjVJoI5xxVQ0P3emhRBR9Yha5iQaK5DHtz FPe3NwlnAgN/jUmraWiUr3ADnzs/X34= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-589-QTdB8Z4ZNfyt4mQQAgw0YA-1; Wed, 22 Feb 2023 12:28:34 -0500 X-MC-Unique: QTdB8Z4ZNfyt4mQQAgw0YA-1 Received: by mail-ed1-f70.google.com with SMTP id c1-20020a0564021f8100b004acbe232c03so11440634edc.9 for ; Wed, 22 Feb 2023 09:28:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lQEMvrvrwWUFc87bAMj47uqR0LzAryMK3MqNTl4bkt8=; b=Ab+ywdoIcvvPTb9SA8TWgqmulEtdnLNk8LzVcN+bbsFNNqWFj6rQON3QyZ67Z0/ltg L5MSmUpcfMFrfNozZYqbPA+J7PrlXyjjLVrwXqDVSqDiQ5wXLphe3K9ttdPiN53U4BHy QPUZQ4N8XJRrIGFYOxxxwCoxmknF3P/53w1lhIITjdwBY+4l6YpiExQJBmWFnp45X2oo q/rq+n3LUzwYSXwiR2gRN5qFTVp9vGAa+CBg3QxBeiDbE+i24SHAV7QxU7aFMPAsKo3f M8lXlNMq+RFayMWQvbYibjBe552K8js7uBLke4fPkQ18JmHasdCv6JCrUVuouT6OUO4w KsfQ== X-Gm-Message-State: AO0yUKWoI4ge7QpU3dmfqNkcvtD4YT9HoAcYx+oAv7oStGTFqHL0HhrW JRKmAkZ/YBXgczWWtHgAoyBD7IrKrB/VlSyQH+T/8vx2CeiNK6aEHSnzgomEQtsVjkgDZ7E2WgJ /BN/y3IzkZgI= X-Received: by 2002:a17:907:9849:b0:8b2:37b5:cc9 with SMTP id jj9-20020a170907984900b008b237b50cc9mr18174564ejc.17.1677086912700; Wed, 22 Feb 2023 09:28:32 -0800 (PST) X-Google-Smtp-Source: AK7set94oya+ivN5E0zBN+ZdUeHEWzDxgBB5z1krpgZihRLpdYMOicX3tApmaLmAqifgXi7BlCrlcA== X-Received: by 2002:a17:907:9849:b0:8b2:37b5:cc9 with SMTP id jj9-20020a170907984900b008b237b50cc9mr18174547ejc.17.1677086912440; Wed, 22 Feb 2023 09:28:32 -0800 (PST) Received: from ?IPV6:2a02:810d:4b3f:de78:642:1aff:fe31:a15c? ([2a02:810d:4b3f:de78:642:1aff:fe31:a15c]) by smtp.gmail.com with ESMTPSA id z10-20020a17090674ca00b008ec43ae626csm16880ejl.167.2023.02.22.09.28.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Feb 2023 09:28:31 -0800 (PST) Message-ID: <99d72837-894a-44c0-4be5-e20755ebab10@redhat.com> Date: Wed, 22 Feb 2023 18:28:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH drm-next v2 04/16] maple_tree: add flag MT_FLAGS_LOCK_NONE To: Matthew Wilcox 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 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> From: Danilo Krummrich Organization: RedHat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: A7CCE180016 X-Rspamd-Server: rspam01 X-Stat-Signature: zzb3j1zs66i5qprhha7qkg5xmyaufzbf X-HE-Tag: 1677086915-965219 X-HE-Meta: U2FsdGVkX1+lZ/vcx6yKg1Pf+7GOI6Ee2Uor2mxjhPFIYnjdegLcU9RwcSLAz0RfmLyfvhvNfeGXCYneG5x5uMFTXFDNAgbvJlZ7xqfudKnn4uB2JlRcbjfSWIcagtPGhtW2rK16RG8FZSMl2U6MQzbCj7BNCsmBOD2IhJRf5mOZmyWyLk5Xtl876w/PbW+NDFIFhZbZMXpkY84g6nL25tyB+h8EwsiZYP0ZQkt2zZIiEZh5XnLBFhV/QCZZbcKI8u/ax2zqijKEi4QsVq1BdfIqrwO9gfmPqc3FToWzjkYs6UxR7vEbRjzi2PL514Zn8IhV9M4jBV4m84LK5WajrCZpPE1pEoKnPq8THjmYs1mgkuR7DoKl56Tva7YEVvfb9oD49Rz/TnfPhkVY4rJH6+83QsPQ6MM8z1otJ4Io4UboeoZFubhREzxWxDkqhQPTsGqPxLhnm5NInop/3i/cuYabXKADy3Q/gCAelLTdeS5rX51m7Eq/Sz9n0MTpfqQ9UAChhTKDdcNZpTCBWMc+BRZHm/Ur/3ShtbZIntXb4ii/jazIqon9er5F7hJwzZqAV/yljA5RFIkvnsXsYCzOdyq48skRKYciTJWBvBFJMBgShCBiJrqoD/rLnSDRlx5bldoxe8C0Eke0gUgZw9T/PYfWl9JUpS6wJ3svRQVvcxQS1xXqT5YnFKXm0MdJEpDj/bxisxXbsuOIJfDtDEDwQ9U2PT2skdCHgFWWUCHKVAp5KgspiftRyaijPVabkxd60zYYyNoCd0t81Q0nsGce/MMtTiwXG6veGnr/CkHJKXAQCgwb/z7voew40UqFTnD67WW3zdBHkNncIz2TP/BkS4dpAhg2knCo1YoFaP1PwiIxNpnb9BsVj9A7ZZnFvQoKPEjEUTv/QOvlIORPYKpRGkS9Q36AZSSoo3mggjrYBGIUYO2hGXQefokHXnbdn96AZwaily/aEOOZg+sEJ7K trgNSRQR zdbMdut8NdjRwLwtSNIC+eqfORp+4ATd5lyCcZTdOrkNwLfplV57ZcXgGeq1iO3W7Frcvpq53vgJQN9CtGuF5x5nqqO1UvyBHdDpDZJGj+T+qQqH49zNADTqBF6oI5qfzK9MTlKyaUmvr43fguhZYO+wa7C3SfDcDCZO5eu0GtQWb55Dv4lBeRAwcnZ8ftWXduRnySLJilg8WVVYU5rwmN74Eds2Zx9YiW6MOhtof7QJxTeYFEgykq0Y2kKkxPCQUN6SMv2UYxVdDCVI15yVJSElNmBne959pDDrv+i0DZmt7WaD4oXmCPN1VZ1tCiPRWfeNI7QSM5DxQVg+zX9C+Lo0nQ/+g6CCO2EHelc3Y2ui4jYCT4Ib0xxPgpQ9y4LNPrm9qUkMw6F3EOdKxIYZcNVIDvTP5zFiZIf05Nt8dWIxId0lzuNXSSL5uxlBddUtXhFs0 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 2/22/23 17:32, Matthew Wilcox wrote: > 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. Again the disclaimer, I'm just sharing my thoughts from the perspective of a user from a generic tree API. For me it feels like - and this purely is an assumption, hence please correct me if I'm wrong on that - you consider the advanced API to be more of a collection of internal functions not *really* being meant to be used by arbitrary users and maybe even being slightly tied to mm since it originated there? However, from my external perspective I see it the following way. Even if an operation is not part of the 'normal API', but an API called 'advanced API', it still is a generic API operation being exposed to arbitrary users. However, my point is not (at least not exclusively) that I do not consider this to be safe enough or something. Its just that I think that when the API *enforces* the user to take an internal lock at certain places it can also just take the lock itself no matter what the API is being called. Especially when one can't rely on this lock at all for other (external) purposes anyways because the implementation behind the API is free to drop the lock whenever it needs to. > 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. > But the argument also holds for the case of using the advanced API and using the internal spinlock. If your requirements on locking change in the future every user implementation must be re-validated.