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 453BBC05027 for ; Mon, 20 Feb 2023 17:45:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 58A4D6B0071; Mon, 20 Feb 2023 12:45:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 53A3C6B0072; Mon, 20 Feb 2023 12:45:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DAF96B0073; Mon, 20 Feb 2023 12:45:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 2F49F6B0071 for ; Mon, 20 Feb 2023 12:45:47 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 022981A0181 for ; Mon, 20 Feb 2023 17:45:46 +0000 (UTC) X-FDA: 80488397934.17.58B6B85 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf06.hostedemail.com (Postfix) with ESMTP id B5C3F18001A for ; Mon, 20 Feb 2023 17:45:44 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=XQcIP864; spf=pass (imf06.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=1676915144; 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=p0Izq1sT8yQqR3StJyRIa9aUpeGU1pXLanSYRIGX2E8=; b=WpPM17nrTMS/hfB8UpMgpeRGoPqYE2iAoIHcHLK+/S1lz4wbUjDJHitqLWdmdHh1f68pgG RukRdLJ8h9rE+KqKC09l1vMe7jE4gInmLb6VsRzHtlKl47/9oGUfrdCrgLOklyGoByTpEl +SwmXK3IFsLljiMeyMnnAxhQfdFOsII= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=XQcIP864; spf=pass (imf06.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=1676915144; a=rsa-sha256; cv=none; b=tLJmPT52904HaPHjexPzc8VCouFM4IangR/1xSsfMlZqNV2DUkKfSjxlds7IVcmDHKHOeL hW9dLzzofGQZjihmQP33dUlgKnCVzOAX0Vp982uKHyL9kLxT8cDrBKFi10/27xMFZbxk4H tu7D/Dm8rSHTpJmKsvyUEKtTxUIWXr8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676915144; 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=p0Izq1sT8yQqR3StJyRIa9aUpeGU1pXLanSYRIGX2E8=; b=XQcIP864uhmQFWV8qlbsVObvqM8toXENMf5nyCmD1QBxvNZogofNJd4pG1/DpjiQ8wQeSv dAPS2523fAGnuLjZw7Cr8gWPGO/Ory8Dz/MqnWlUspAhqV7TSVA+SYKfX7IczPT4SZS76c IasvKBoeJ2Q7UAUlhHXLpfskglq0MAE= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-483-57HW-RMXOxWmnebGMTBMog-1; Mon, 20 Feb 2023 12:45:41 -0500 X-MC-Unique: 57HW-RMXOxWmnebGMTBMog-1 Received: by mail-ed1-f72.google.com with SMTP id v12-20020a056402174c00b004acb5c6e52bso2289165edx.1 for ; Mon, 20 Feb 2023 09:45:41 -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=p0Izq1sT8yQqR3StJyRIa9aUpeGU1pXLanSYRIGX2E8=; b=nHF4RN195i27G7F1q9IKK79mX7urFnlXU8WbrHzKHAbugcBx5xgIQJHtY0TemHniCK OwMt60ym/uiG5shBoJAzPyKGPMcff2zbdK2wuB7RSUj070ht/VJsGEsj/m+/GYMXEjud NewiV31Sh3zstV3NU0ZTPSxMbgpuYB6S7YfKWKw5IKpfFNwGo442fKNCBWR3kqRV2s5q 7ix+V+SRqSa7j86iJAj1MTQ6C1X7Gtfrt7ib0ykSUXdvtPR2VspVd16G0uNDTs2788CH eThO+Jm8PjiAOlDKHT+VTahNj8AJ5p2DicRyRGh7C3nnWBCuwnFykr5BPbDJcVwPAI3R uMvw== X-Gm-Message-State: AO0yUKVZH8Q/pme3JlFx2fZ6ws6GwRnxCDOoVWciDa/lUPmvKMDIse3Y qoHx9clE7sPUTm7/1dxmkftfq/DJ+LTU3VVhUZwMhy/m2280bsBLLlj+qONrkHkRKEbLsngyhLW afBwi0SYk8Rw= X-Received: by 2002:a17:907:94c5:b0:8b1:319c:c29c with SMTP id dn5-20020a17090794c500b008b1319cc29cmr13659857ejc.70.1676915140668; Mon, 20 Feb 2023 09:45:40 -0800 (PST) X-Google-Smtp-Source: AK7set/Ga6rG3Eq1hZqRFlC9SxeuFv04ZCxlmBzWk9HFcUACYcpXem95hxGHCYiEqsp+Ho5tDk/t+w== X-Received: by 2002:a17:907:94c5:b0:8b1:319c:c29c with SMTP id dn5-20020a17090794c500b008b1319cc29cmr13659833ejc.70.1676915140411; Mon, 20 Feb 2023 09:45:40 -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 f21-20020a170906561500b008d09b900614sm1826220ejq.80.2023.02.20.09.45.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Feb 2023 09:45:39 -0800 (PST) Message-ID: Date: Mon, 20 Feb 2023 18:06:03 +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> 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-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: B5C3F18001A X-Rspam-User: X-Stat-Signature: pywcyd3u3i1hxahydr1hyjgn5qcx5gpf X-HE-Tag: 1676915144-194975 X-HE-Meta: U2FsdGVkX1/sEKrkZjsmtUAJ2BR18iL0M2n5SZ+TQNsE+aYUdUDM6tXftihGynKTrql3aXVqpX45c/sqAq+S7RPfjr2DTLxtBWb9VqUWuvFFZuRKpWuUd8l88nZR0O0HfXBRFSaBMmRKF8sDy5L6Tis5iUQlUOfWnV8YY7ZNbNWGnskC2Y4vfIhb7fHP5iy1xu59hPEnIF+7KGKPmArgOwXwhSkIsZnseLLss6bRcSjaes7LeCvq2yslG518lKztNgCIKfJdEysdbhTO9fPKRWACAfBIbPbj7vi8kHODBIGfK6jsvclQArPHtNNt4wV6yWq2qXdTyed2toX3zfSgTonJgbCvyrqRbejxA4f4ENYvhh54uhkVDDRy8c4nVp8HkgMK9ZxCTPgkpkie9PSSgDWAyWwmmRAH1IoKB29rhX5OaV+TlNrplNhJrhh7n3Jtg+LlbLaYu3oLujB8QZEoQ3O8uRsaUSComuVh5WuwTtL3VYxRjFtRJSzgy4BMKGxcp/+gtY+QkOol76TZ/0ydBRf88PkmgtY8x/g/NZsEJsnKYUZIg0VWay3Sg7BS6Otgzj3qu69yabR8r7495knoEFhsImnInjogo8hBNxuLcMEOIuVlFSmrEyuq3Or2TTSjOZnrKx9eyW1N35BzXpb9TqYEdzSBrPNtinTjP395mXJtUoKAyj8MnjWB6AUVtofPDIYXN+NZQYVNRep3GHFZa7OQO37Z62qyophlv1PgM++KaXMaBw/t5vrmMpPrTzATR0wTZ2dXZay1PyHYeMZ42SS30+IReYrT4fZxGpUYaEEHmxDd4ipSMLxjn7YykDodi36AhfOvJq+WFFMO0faX9Iuqgy/i4I98A3j6s4YfADq9LO79Rde6oP4bOjlYY31XnnAdwL66EnkurW3/5ZRzreVr9N7CgV+l7GqOmA5mAdftgWr4kKmVd69Gb2GH77Hzypm9NhDsGh/dUHLTBXA o3QI5WDF 2150v/nc8Dky/yod3Si0Y1Zz59vdbJbpG6SdhnJGOB//aUVLR5IcQbJxaorJwDvf01Lq6C0fXjxhzk+CPaqgyY9UrgQoE3BwSkIGMY+ZzgCenX0D6QbihnB8J2hodQdInffpCzeB8r5f4WlJFwDfWzca1kyeIlVHI8PmI0NrjJ6ujU05UHLYonop/kENO5IhqZSv6o6ug9w1YfE7jyZgDvx3QJfAp26VBK8L/mTgCam4wVy7X9lwZQJSuwZ2JbOiIuheeBoNKqqWoTI5uIaoQ++imRsroso1EUAbOIVpuzwtZZLutTahMS5imAPwokn05z2PBLLTJP5Qc2idZn0/KsAU+HfHJUar4Y8FxIZbXe/+cYWBTQykp9Vp+ofvOclxvdAIV177VyS+Pi4l27FVUbPeMAhDttb2l4gN6zWe/FcFUSypWS+HqhyQgf1npB5LIDSdz 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/20/23 16:10, Matthew Wilcox wrote: > 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. 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. 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? > >>> 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. >