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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B96D8C636CC for ; Mon, 20 Feb 2023 14:50:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232122AbjBTOu5 (ORCPT ); Mon, 20 Feb 2023 09:50:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40924 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229671AbjBTOu4 (ORCPT ); Mon, 20 Feb 2023 09:50:56 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 033C21EFE5 for ; Mon, 20 Feb 2023 06:50:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676904607; 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=14aOzXv8/LFbctYEfZwWWmrtrURJsidYi3oSxaFz0Xw=; b=fps2RL9aHJXpDc0HM//MI5bcPOIQv1V0SxEgNWsB5WBrjI/QPs6B4GeCwVLdxwELgykhID 1oUitli2gIyvchuKO+oFLnDXZJGjp1kTw3AmxNzc4c1XlGyuOeHssJFgdUR9ylO+n6zRfV dO8DpUoPtla4YYxeZdQkVrC3BzrzLOM= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-637-KOJKgUNmM4GOx_23Dr-ybw-1; Mon, 20 Feb 2023 09:49:58 -0500 X-MC-Unique: KOJKgUNmM4GOx_23Dr-ybw-1 Received: by mail-ed1-f71.google.com with SMTP id co14-20020a0564020c0e00b004aab4319cedso1528897edb.2 for ; Mon, 20 Feb 2023 06:49:58 -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=14aOzXv8/LFbctYEfZwWWmrtrURJsidYi3oSxaFz0Xw=; b=Z5X8HOLb8D0+KbuoKS8tDc/ih7Pkz/O2xiNDLmwxL9pm0/9E2GRVd4/+7mVoCQvfmN G+8JPjH5DuxEBtyvXfgrSAFokKE680cO9vpyln63Yh+oScAAFs257pQQgducR5LD9eAf yqO0WF3Hqaw2lS1pT290rJ9ZNcFRbRCQbvnL7XMncrD7vRBq0IZIb+/Wd/EDnZSzw8XE ZjjPHdqCuA0OWCQmlB7dDgP4hb1MGiRu16fMlk7PA6VDIqSITu2gPSGDFbgYD/eEVvuv kJAsFSuAnmQRL0z6m5C4h48mN1EwM070TkM32N0KL9Xs9DxTrItpmqmF00R0ccRdyLWf Rpdw== X-Gm-Message-State: AO0yUKXj3WqG1VwdS/hNX+uDzq6IUUBdSN3Af9V6qp2AaLTe6u97sjjq J+ZRHnHwYAjW7xpjFSwD0QT/1BwlfP9p00h3uNZzA6b/B1/q9K0MzlUw0GIsHCAxaWmpy9acwMf aHqIRe7Q9ChwdBo7tmTGh X-Received: by 2002:a17:906:c451:b0:88b:4962:b72f with SMTP id ck17-20020a170906c45100b0088b4962b72fmr7384958ejb.20.1676904597385; Mon, 20 Feb 2023 06:49:57 -0800 (PST) X-Google-Smtp-Source: AK7set+98u/y2Cal3np2ksbwfkOOCjcq6rtCsH8aYGEsMo5bVtK+OVJWU6UbYetsNggJNxfOhh/MAw== X-Received: by 2002:a17:906:c451:b0:88b:4962:b72f with SMTP id ck17-20020a170906c45100b0088b4962b72fmr7384942ejb.20.1676904597149; Mon, 20 Feb 2023 06:49:57 -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 jr14-20020a170906a98e00b008af574fbfc2sm5934451ejb.33.2023.02.20.06.49.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Feb 2023 06:49:56 -0800 (PST) Message-ID: <3bb02ec3-4d19-9135-cabc-26ed210f7396@redhat.com> Date: Mon, 20 Feb 2023 15:00:59 +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 Content-Language: en-US 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> From: Danilo Krummrich Organization: RedHat In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org 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. > > 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? 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5F7F7C64EC4 for ; Mon, 20 Feb 2023 14:50:09 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id DB49110E1D6; Mon, 20 Feb 2023 14:50:03 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3E2F810E120 for ; Mon, 20 Feb 2023 14:50:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676904601; 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=14aOzXv8/LFbctYEfZwWWmrtrURJsidYi3oSxaFz0Xw=; b=W7utZUb+//mYlIVvizHkahjFJknb2yDNePjDFCSemrxS6HSYp0OEntkzFpIJVZkv/k7uyR nIIVtFhg0WKqWvR70reBoPiMoeNie7LBlx1TwfbweYzMeDz6HFKmJuaj+FqwUZt6pvUUXD pohqJli5lk00+o0iM7qPZWrEkPVkCO4= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-315-AAkqfDkbNziWueqdWmxrGg-1; Mon, 20 Feb 2023 09:49:58 -0500 X-MC-Unique: AAkqfDkbNziWueqdWmxrGg-1 Received: by mail-ed1-f69.google.com with SMTP id g24-20020a056402321800b004ace77022ebso2095274eda.8 for ; Mon, 20 Feb 2023 06:49:58 -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=14aOzXv8/LFbctYEfZwWWmrtrURJsidYi3oSxaFz0Xw=; b=RhVIQ1TV79uiBf3TIyqNinx8rOj8i0VPXKCD3+eEmTY9wx4odmG0LlcPexo9Ii/Pb3 BsiG9JxVjN1PIztrN3GPkYr7qd+hRUrKzM170xbrzxCBk+YkWMpiKgygXCgn/6Evt6A3 TexS6P6Cj6Z8Bfbm92WaQRfvoAMflcEDTLkSO8SK0CF7EX3sCP48EXUNGINkhERrfF0+ QcUp7iiihwOHequ1VJLxQFhUJTkaSORYMiUeo4v/P0VhH5Evn1cXbdCvYTlTYi0K0VAH ZqKAi2geODIHmoQTj/8CtU2UqXmnsz9LmJdIynn1ErWx64oUYMjcXOJgNMD+umxcwuif ybAg== X-Gm-Message-State: AO0yUKWu/smaBhjQHoQH7fgnww47Ct5oOVDz+x6k7LfYxk83P1oI9/8i Qh/KidZKA4o8pOCCGwP0CJhfJMws3E+6Yp/P2YPVJqbCav+sZLjrFhWwrBcCQEiNyPvc0pp4XMg tlPOGZbBbd7+KW8mFfpA1iVyUXg== X-Received: by 2002:a17:906:c451:b0:88b:4962:b72f with SMTP id ck17-20020a170906c45100b0088b4962b72fmr7384962ejb.20.1676904597385; Mon, 20 Feb 2023 06:49:57 -0800 (PST) X-Google-Smtp-Source: AK7set+98u/y2Cal3np2ksbwfkOOCjcq6rtCsH8aYGEsMo5bVtK+OVJWU6UbYetsNggJNxfOhh/MAw== X-Received: by 2002:a17:906:c451:b0:88b:4962:b72f with SMTP id ck17-20020a170906c45100b0088b4962b72fmr7384942ejb.20.1676904597149; Mon, 20 Feb 2023 06:49:57 -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 jr14-20020a170906a98e00b008af574fbfc2sm5934451ejb.33.2023.02.20.06.49.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Feb 2023 06:49:56 -0800 (PST) Message-ID: <3bb02ec3-4d19-9135-cabc-26ed210f7396@redhat.com> Date: Mon, 20 Feb 2023 15:00:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 To: Matthew Wilcox References: <20230217134422.14116-1-dakr@redhat.com> <20230217134422.14116-5-dakr@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 Subject: Re: [Nouveau] [PATCH drm-next v2 04/16] maple_tree: add flag MT_FLAGS_LOCK_NONE X-BeenThere: nouveau@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Nouveau development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: matthew.brost@intel.com, bagasdotme@gmail.com, linux-doc@vger.kernel.org, nouveau@lists.freedesktop.org, ogabbay@kernel.org, corbet@lwn.net, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-mm@kvack.org, boris.brezillon@collabora.com, bskeggs@redhat.com, Liam.Howlett@oracle.com, christian.koenig@amd.com, jason@jlekstrand.net Errors-To: nouveau-bounces@lists.freedesktop.org Sender: "Nouveau" 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. > > 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? 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9234FC636CC for ; Mon, 20 Feb 2023 14:50:03 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id DDCA610E120; Mon, 20 Feb 2023 14:50:02 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3D51A10E120 for ; Mon, 20 Feb 2023 14:50:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676904599; 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=14aOzXv8/LFbctYEfZwWWmrtrURJsidYi3oSxaFz0Xw=; b=dJjDqq9nQeGAtaGn/elYkQbmnBvbpDrw1X7OUQKTwZJiInENZvjZL7V6TNiYkReuUVKEke jEIs0SlRZs6jw+u9iaUVHv5n1YXXE+Dvs2XO2xRpBTw8inIndPCUmBwJr0tHyIZuvT4dPL cJjzlCdhSvyT2EWuuBRziSY2o+9udfc= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-637-uYRZ0B0wP8a4ldB5hS_zow-1; Mon, 20 Feb 2023 09:49:58 -0500 X-MC-Unique: uYRZ0B0wP8a4ldB5hS_zow-1 Received: by mail-ed1-f71.google.com with SMTP id ee6-20020a056402290600b004ad51f8fc36so1711753edb.22 for ; Mon, 20 Feb 2023 06:49:58 -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=14aOzXv8/LFbctYEfZwWWmrtrURJsidYi3oSxaFz0Xw=; b=QAplcJHWZFM+HGayQIcGjhQWtqqOHqo6hS3sIksufQeSssEQx8XN4HKNfchIrTDgxy NhcU5BeP+P28M1GxTT89ONiYgE7aqOIzMujNgGi2tu2aOwpoAGyalI5M0YKKXGdjhfmH xrmgm9UujOsyxYFj5RuxsUQ3Mya/JNhArp0eDYCs6P4sDOn+FHEWZnMFa0tQgBN7iuzr JyAERjxSX+dJkpXzMwNa+apvHF8xzqBTsnocuV5hrVpEX5KnhKP5bDELgmTvSMtpm9WE fxyBwdbKT1r19lNwUr1jma2zPKu0LLBIskQCcUt/XttT295SIC5w9VrOoyzN/WwN8hIJ Ql5g== X-Gm-Message-State: AO0yUKUtl7Fqn4i+VkUyK0LffkAE3MtSddR2StqjfcHzzIebDi2rIPVj /JzVin8fzElLdZ1ry3x2lsP1NXx/9lWw1bYQEObyr0Y/mkiIoDFh7kd591AALETMhBWrQqEUghH WSfZMLW/o5bb69NY+fWOJGtILYqAv X-Received: by 2002:a17:906:c451:b0:88b:4962:b72f with SMTP id ck17-20020a170906c45100b0088b4962b72fmr7384961ejb.20.1676904597385; Mon, 20 Feb 2023 06:49:57 -0800 (PST) X-Google-Smtp-Source: AK7set+98u/y2Cal3np2ksbwfkOOCjcq6rtCsH8aYGEsMo5bVtK+OVJWU6UbYetsNggJNxfOhh/MAw== X-Received: by 2002:a17:906:c451:b0:88b:4962:b72f with SMTP id ck17-20020a170906c45100b0088b4962b72fmr7384942ejb.20.1676904597149; Mon, 20 Feb 2023 06:49:57 -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 jr14-20020a170906a98e00b008af574fbfc2sm5934451ejb.33.2023.02.20.06.49.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Feb 2023 06:49:56 -0800 (PST) Message-ID: <3bb02ec3-4d19-9135-cabc-26ed210f7396@redhat.com> Date: Mon, 20 Feb 2023 15:00:59 +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 References: <20230217134422.14116-1-dakr@redhat.com> <20230217134422.14116-5-dakr@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-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: matthew.brost@intel.com, bagasdotme@gmail.com, linux-doc@vger.kernel.org, nouveau@lists.freedesktop.org, ogabbay@kernel.org, corbet@lwn.net, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-mm@kvack.org, boris.brezillon@collabora.com, bskeggs@redhat.com, tzimmermann@suse.de, Liam.Howlett@oracle.com, christian.koenig@amd.com, jason@jlekstrand.net Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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. > > 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?