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 B1C63C61DA4 for ; Wed, 22 Feb 2023 15:08:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D96966B0072; Wed, 22 Feb 2023 10:08:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D469D6B0073; Wed, 22 Feb 2023 10:08:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C352A6B0074; Wed, 22 Feb 2023 10:08:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id B18F06B0072 for ; Wed, 22 Feb 2023 10:08:24 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 6EEE5802C0 for ; Wed, 22 Feb 2023 15:08:24 +0000 (UTC) X-FDA: 80495258928.24.31E394E Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf11.hostedemail.com (Postfix) with ESMTP id 2BAB24000A for ; Wed, 22 Feb 2023 15:08:20 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=CBlq5PNG; spf=pass (imf11.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=1677078501; 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=zRCEb4SvpDKPjZLK4vn9/q7q7Y3I8z1o20cZm/AYJwk=; b=YZBlwVfO7/0JRsKt+YE8NbdWbv0byVVeMPOLPKETRtvLz6k0OHy8jJL1Dc0pU1LkoppYHY xanhgZArEymTUX+6N49Y4Yz+sPqp86kkudUHcqTKII4pkINMBxOuQIjNdmytpfi/ZZz3zU fvAkVLrIFIAiO7Wzd5OojiCuJRExeeE= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=CBlq5PNG; spf=pass (imf11.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=1677078501; a=rsa-sha256; cv=none; b=MrAmMNfL5aA5amc9mKZZUGe7mMq9bImUZPEA5YWYPjGpl/02F+9XFexN4moWbBnEPDeeW/ PtAFUDbOftJZnTkEM8FvcfzXsQO+Tn7rI66f8qIJjTJM05bilkH65zrilZk/OnLX+3u9o6 vrdgR+tH5geRJe0pMtzNAMNyGZeriok= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677078500; 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=zRCEb4SvpDKPjZLK4vn9/q7q7Y3I8z1o20cZm/AYJwk=; b=CBlq5PNGPeX5MgSXwsZitJUd8Rl53Shn41YLydXjFGqUSO5fhryS/JY8AfDaOIMFkS8Gf6 K2yfPj5z+vVbZCKPqVyNR7Mjpl/RD5tsSQY24V1BDJfNJZtPK1yxp8mAArDKFUnv0/S0hN KvWwA99WRu6jmqVWwzqAvFOTmHj21hA= 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-329-z8hLgoC3NHyZEZBY7Cld7g-1; Wed, 22 Feb 2023 10:08:02 -0500 X-MC-Unique: z8hLgoC3NHyZEZBY7Cld7g-1 Received: by mail-ed1-f71.google.com with SMTP id ec13-20020a0564020d4d00b004a621e993a8so10963022edb.13 for ; Wed, 22 Feb 2023 07:07:57 -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=zRCEb4SvpDKPjZLK4vn9/q7q7Y3I8z1o20cZm/AYJwk=; b=nvKobYzjZz0mNH308VC8UAJ7onaPNICu1102clux3J+VLheCyFG9Cvw6tSa7MxC6Gu HhMKVvvSvDYs1iK0w/TT55/+CTLSvJfJvc61OZTlJIOAf85L14JwhGi6Bg+wEeqVJ4YN fiurc/CF1ls7Jmy7P/CYTNby3Tl7MToxQTE7MVrUChyMs5I/h0X9Sr9PdOxQEAfc+iWj KDzqU2RlxjsVAAnfRyFsulvfKDfD9O3rzZTDVXIoTJD55ZUUeKei6YF+n1pii9OIjDNM 3Mj1j6yvgZ0g/UirpsE9yPDhXTG5ef/RTui9ywciK7FfuweQtCWuXpR2p35JBx1tKGlY c9Fg== X-Gm-Message-State: AO0yUKVYYe1IouXM+vQ1WIIWLaCW4t8Vg0q3/y0yfRcZkWrHfq890pJ9 iEcU/hL8LgqHemFrIKcBKQok512ZxX6ya8QMj7ufkaWS1TTBP0U/QwZf+da3ah+aRf5soRVwlvv 1mDiR+Ak4SG8= X-Received: by 2002:a17:907:1623:b0:8b1:76dd:f5f6 with SMTP id hb35-20020a170907162300b008b176ddf5f6mr29151566ejc.50.1677078475602; Wed, 22 Feb 2023 07:07:55 -0800 (PST) X-Google-Smtp-Source: AK7set8V2KGVMm3Rh6GnmJnl329zmNElexUMuVrYhLPpVZhOY6NIjF1ZDTeKB87CfdRbYWnWGPbc0Q== X-Received: by 2002:a17:907:1623:b0:8b1:76dd:f5f6 with SMTP id hb35-20020a170907162300b008b176ddf5f6mr29151515ejc.50.1677078475224; Wed, 22 Feb 2023 07:07:55 -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 q20-20020a170906771400b008e57b5e0ce9sm1160273ejm.108.2023.02.22.07.07.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Feb 2023 07:07:54 -0800 (PST) Message-ID: Date: Wed, 22 Feb 2023 16:07:52 +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 05/16] drm: manager to keep track of GPUs VA mappings To: =?UTF-8?Q?Christian_K=c3=b6nig?= Cc: airlied@gmail.com, daniel@ffwll.ch, tzimmermann@suse.de, mripard@kernel.org, corbet@lwn.net, bskeggs@redhat.com, Liam.Howlett@oracle.com, matthew.brost@intel.com, boris.brezillon@collabora.com, alexdeucher@gmail.com, ogabbay@kernel.org, bagasdotme@gmail.com, willy@infradead.org, jason@jlekstrand.net, linux-doc@vger.kernel.org, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-mm@kvack.org, Dave Airlie References: <20230217134422.14116-1-dakr@redhat.com> <20230217134422.14116-6-dakr@redhat.com> <70ba382f-1559-289a-4922-ca9c371aaf59@amd.com> From: Danilo Krummrich Organization: RedHat In-Reply-To: <70ba382f-1559-289a-4922-ca9c371aaf59@amd.com> 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: 8bit X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: 6gx4s4nhmraigkumsw98785jmink1tu4 X-Rspamd-Queue-Id: 2BAB24000A X-HE-Tag: 1677078500-56497 X-HE-Meta: U2FsdGVkX19i2DuCfXmK12SXDlZ85/m7fOqLGLDOBookM46iLlysUOIHeWmb2kwp4YwYmHMloUbYXOcDg4u6IvtUCbTp1rnDtXdTQdzTEyR3hbYaTY+mXnegYcxxVKI/TF4/3+9Mo6Es9XDmjBnF6JMGCu8UMCFj9A62leCHeNinR3txU3CogREhm5wRyROmT8tOEvx1nSz8F/fk7ZFGhDtkIxbem/qGN9ItCbjHOTPlUSPvRRw2js9sxC4wjl/Kkk8fRyPLZgUrwnDfwKBdteebgYAWHnW79UOKmqRB6D9KlaNcqZawaIVLe8Ec8xWLG54wxKkeIRNe8KHYddvRBNXROY+9yn/uKueNSBsV+hDxvyPaLqT1Wvdxdr01Gezt0hrMjAo1VErQr9DdicaSTQ0gMlnyk0xF2ZTNMcE1psr2Z5eHNh/N9AqTyHd1rtsTGwNS1Ttfnk2TPStmtRZNTTS/pFqS97nOJAVU77O3sM44u+0XOho1Z498Fp830LkgoQ1fiGr2aJdjhM5T4Q98zooDE1zDf7CPJKjU4IiE1NUV9kqdzQpjuOdz7HfAZn5uIsDlkYqNv4E8jXEhJV7rUpCczLyVV6FPVh9z22RgaJOqPD6M0pcyB/4OhFU4F+Kdwplfi6S166vrsJYbwRORYdP65Fgse0icTBKgqRwiMOwu5EBEX1qWi5iJ6pdqMXb8GZb5wtOAQDyf+xxnnUQZLsDy7UT1kM0xLyR6cBIfkD3WNgcjUCGKTS8eO4Ll1y0cGr5i/eFer1G7XhB1E82zJZWnRsO/aMhIOq8qDlBVVd6K7M8FcrAj3DChIjzIu12lOi72XR3dl42OL4fmnf7wl8lGJA+yoR0iPwm9pvjjyd9S1eHe7yGUttp6Dv4qGy/cD50RG91G6xVyqLf8wija+FZp7HgmuOpVxD/pLbX7BWFEJcI+5m/G4gMfm8A/2TGXOISYrTvDv45cV9pF0mG g+Mk39ve 82+t2vWQEo+3d/lxc2fZ87xcntLEKzKUPeNjEHCXSUUxCsr/VPpc1EmEdHo7LKjallUOhA6bBlJyBvr7JKThH/r0uZT6kktt38vlKn28jGSZ/iUcftf2gRTApgMxtP67aeGOWer3jnX3RxsQuTzWhUbaONAXZ6c24FMKZcXfwN7IhIHflxpxk11yfd+6vyqr6PXRJXF8aERGwsCxGKWSQQ8fu0+PASW6cHL/ZZQJJkLBieIZnfjn+UYd8C1C1QOH2PFFQiR4ni/rlUMf79iASXGToCT94VcohUuo9WUfwEYt+8UF7u6ZaxWIqNjtA9Aa1wSnm6HTL9dJEIUdhvEcz++fbTXkHRHqJdbo7IMLEqRlW9+vOrWdXIwQJ1WbW2dJIsCF0o1FKsJ4QgfRoAQuCL7qnhA== 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 11:25, Christian König wrote: > Am 17.02.23 um 14:44 schrieb Danilo Krummrich: >> +/** >> + * DOC: Overview >> + * >> + * The DRM GPU VA Manager, represented by struct drm_gpuva_manager >> keeps track >> + * of a GPU's virtual address (VA) space and manages the >> corresponding virtual >> + * mappings represented by &drm_gpuva objects. It also keeps track of >> the >> + * mapping's backing &drm_gem_object buffers. >> + * >> + * &drm_gem_object buffers maintain a list (and a corresponding list >> lock) of >> + * &drm_gpuva objects representing all existent GPU VA mappings using >> this >> + * &drm_gem_object as backing buffer. >> + * >> + * If the &DRM_GPUVA_MANAGER_REGIONS feature is enabled, a GPU VA >> mapping can >> + * only be created within a previously allocated &drm_gpuva_region, >> which >> + * represents a reserved portion of the GPU VA space. GPU VA mappings >> are not >> + * allowed to span over a &drm_gpuva_region's boundary. >> + * >> + * GPU VA regions can also be flagged as sparse, which allows drivers >> to create >> + * sparse mappings for a whole GPU VA region in order to support Vulkan >> + * 'Sparse Resources'. > > Well since we have now found that there is absolutely no technical > reason for having those regions could we please drop them? I disagree this was the outcome of our previous discussion. In nouveau I still need them to track the separate sparse page tables and, as you confirmed previously, Nvidia cards are not the only cards supporting this feature. The second reason is that with regions we can avoid merging between buffers, which saves some effort. However, I agree that this argument by itself probably doesn't hold too much, since you've pointed out in a previous mail that: 1) If we merge and decide to only do that inside certain boundaries then those boundaries needs to be provided and checked against. This burns quite some CPU cycles 2) If we just merge what we can we might have extra page table updates which cost time and could result in undesired side effects. 3) If we don't merge at all we have additional housekeeping for the mappings and maybe hw restrictions. However, if a driver uses regions to track its separate sparse page tables anyway it gets 1) for free, which is a nice synergy. I totally agree that regions aren't for everyone though. Hence, I made them an optional feature and by default regions are disabled. In order to use them drm_gpuva_manager_init() must be called with the DRM_GPUVA_MANAGER_REGIONS feature flag. I really would not want to open code regions or have two GPUVA manager instances in nouveau to track sparse page tables. That would be really messy, hence I hope we can agree on this to be an optional feature. > > I don't really see a need for them any more. > > Regards, > Christian. >