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 AA1D3EB64D7 for ; Mon, 26 Jun 2023 22:38:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE9CB8D0002; Mon, 26 Jun 2023 18:38:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A99998D0001; Mon, 26 Jun 2023 18:38:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 961138D0002; Mon, 26 Jun 2023 18:38:35 -0400 (EDT) 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 86F878D0001 for ; Mon, 26 Jun 2023 18:38:35 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 54E9F14089E for ; Mon, 26 Jun 2023 22:38:35 +0000 (UTC) X-FDA: 80946364590.04.D24C4C5 Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by imf05.hostedemail.com (Postfix) with ESMTP id 4BA21100007 for ; Mon, 26 Jun 2023 22:38:32 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=jQFjf4X3; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf05.hostedemail.com: domain of airlied@gmail.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=airlied@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687819113; 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=/4BPPMHxIuX4VVUkfnAZKGZOTCGN6vqENFDffRdr5PA=; b=a9WUSma06lJNtPpd2yeXN05rYwda6SEfpBpmCVaButPosEt10L+FDehoLPGL6bDwLPrACV 38DlXLuBGr9ZT2TPIU63iytCMCYi/AQj72hL8Z7cGvV0RLdvurTrXpd63DQwDfct6Yvuck km6VFNiobKVlxDT0+k3KR0bCS88v4Zc= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=jQFjf4X3; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf05.hostedemail.com: domain of airlied@gmail.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=airlied@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687819113; a=rsa-sha256; cv=none; b=MSXRvxH+qOY9GOWMc7oX3xWicnh0RlhoHV3mnWRshgTfwiF8aRjsUx+yCVw5t+lqhyLJfV +fOQHlidzpKm/jB+g/TPo6M3axSMA8kOTg1AA01eQ3HSAZpepVEhNU7BRmvXmiYUAJz/Sz dj4sbNEQfWTqeMmvXi2dUHlkrPmkDnk= Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2b6a662b9adso17312701fa.2 for ; Mon, 26 Jun 2023 15:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687819111; x=1690411111; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/4BPPMHxIuX4VVUkfnAZKGZOTCGN6vqENFDffRdr5PA=; b=jQFjf4X3mG+0YOiNUYcjsja7cQ+ItKtzN8+vj6u4YVgsB4JaIqtuhMT5UCVUxUJz4i ZEDU69/ocAs3SvgoX+rDPvyDPOlHzbuQz/lyEAYF6L0LH+8LgctjGFNm4Vejo7MxVzDt qiJjofMJtWSRxEVa10tAOWjc+h7fi/7Hv05huAdjtBimk8g1S+ueVSLTo7op4BLp7ON5 jvf5lj7DKxmOb5m6ju6QC6fnctbhz4mgT/io2QdujpKtpLMPYeNaco6tAscDk9Xkz5rQ pWWh3HUFbUIbbkW+Cf/iIIqufSPZY+ydtcQZIpa8QIJJJ0JPVMXz72S6TAns18MhtEP2 apKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687819111; x=1690411111; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/4BPPMHxIuX4VVUkfnAZKGZOTCGN6vqENFDffRdr5PA=; b=XwYY7kgjcTa80jP/weNA95TJjzws3y0nSJUdBSE+PqL8kDd3+Brr4dnKCdvQRKBoa4 cMznlkJ0NjbXsDq89pyEsnRSmcx725IVb2yvm0jLtrfETNGdE3RTAJIIQdsM3eu1IRXx n3p0b3nZImC1pzKBbwuO8u4q0iQnRr7w620XuGh/xiniIzfMe4cS1mFT2bkyK43t/5Pp ZSZwyd+ZyTqYoZe/nhsNDx7AnYqT0+Z5Q5z3SOd3VgR+gRkOwwST2zldR2nMckqPax+y k0y2piSzJXB624ykw9ME1b6vO24l1lpTjZmRltb5GcwJVYBbFkRxEUOQuupTA8E5sYvs 8aJg== X-Gm-Message-State: AC+VfDy6RbLUSWb75e8sjLKlrNyO021P1aGDRuAv8so85m6pgPzFa7c7 GPdPGu5VRleDPwXTBtk+M45YcpEqiDqQlERUIHI= X-Google-Smtp-Source: ACHHUZ6lR+r47SwmWrLOLwTX0weKHcxS2NtYt9q6sHoMoPzLK4Ljmu+yCVm3VJkQRyQVU7ShZUnwFUHfeto+xg4lEu4= X-Received: by 2002:a2e:2e10:0:b0:2b6:9b4a:2608 with SMTP id u16-20020a2e2e10000000b002b69b4a2608mr2962412lju.37.1687819111001; Mon, 26 Jun 2023 15:38:31 -0700 (PDT) MIME-Version: 1.0 References: <20230620004217.4700-1-dakr@redhat.com> <20230620004217.4700-4-dakr@redhat.com> <41aecd10-9956-0752-2838-34c97834f0c8@amd.com> <86ef9898-c4b6-f4c0-7ad3-3ffe5358365a@amd.com> <2f502150-c1f8-615c-66d9-c3fb59b8c409@redhat.com> <4a52ac7c-19ba-8906-5902-fbf75673bf59@amd.com> <923e914f-d367-2f74-9774-f0024d946bdd@amd.com> In-Reply-To: <923e914f-d367-2f74-9774-f0024d946bdd@amd.com> From: Dave Airlie Date: Tue, 27 Jun 2023 08:38:18 +1000 Message-ID: Subject: Re: [PATCH drm-next v5 03/14] drm: manager to keep track of GPUs VA mappings To: =?UTF-8?Q?Christian_K=C3=B6nig?= Cc: Danilo Krummrich , 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, dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Donald Robson , Dave Airlie Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 4BA21100007 X-Stat-Signature: cdcy9in3xgrcsehktc8hziay96wkkyto X-Rspam-User: X-HE-Tag: 1687819112-505216 X-HE-Meta: U2FsdGVkX18GSnHw0OGPcO30RSuTt7co13eZ/UKYODp+xHmGw/AmYwtXaqZNzJ5zdRH8TdejB7CC9iBoChJKrQrWFENaWGM+jvB/rm4rvARO757uwfLpSoKuF2sVqPImdDtxdN2TFRrA37IjQYpPGSJLIv7iitRsbEAXB98aASEs1o4Y/ZYwjNi5SYquzu6W0fhzsEsYiwe1cslGDKevMa8moFBYAFz3GNZR5kMua3/HwJ3/ir/pAuSzxeqkxP/y/7eBQE+KaNBqCeTkzfd8H93wHVzTT+y3uxmq+bojvlJ6ip9NupdmsW9MrTqVZyZKle1DikltKTO/fBLL6FhLXLRylraoB2jy+nm0pL7jLhk+ZspVswhBxH8sarH1NLdVciS904aaaYfcL/GoOWukEH9J9Bz6p+cA28UsNRe63n868Odp2VUmYxsTkFinSeK2jhqGOUbgE6MuJx/z5W262wknRsHAsnrBewxYEhD1wUd0HwEvAE8z2LSTMwUSReUYqCmRhqBygiP+S83uihf+DlgTr1J6GF9ELqBQOPw/f3EpP/HZ2LJFaBPfKSmPhqZeTlHYSdyuZJBVRJshi0rap1q4zvmSNkv8vgbVKtX3y8V8xhpYOT22t+FuJ8hIbNhd0ZnuAYz44O1YMCMH3EACKoJTaPjVO3ZqqNoOFAtuqhC77PYbw2bXxaUJpYaTb5kewDCuZuFrXwslx4T0YnCi6CQob92f+JpM6HqVf3hhxg3eqmHZHBpn2UtZR2Kxbz8WIaWNZDDKbNva+jtyhBMz38761c6rwEme89pUDYbvLAWJXNAFWfP8RC8QS9RxYg1b+B4ImtiP5wo0Jm1QXmcLjRdWNFDQboijK6om8g5zcPFmC08IZIdjs13G7w98ijCZRSPNHk35E6G44jkVeGwSMAKjvdz1IIe2OX1EvKmBy6SvTlwTpcjm6+vRsVwlPR6wjFhycefJzOgJVqbrgB0 NtHkVB5z ls8IevVXwZ/D1FdMOmWjRPGpW+GTMWOd1glMMr/rqgf/Elj8XN51H/hRqautaJu0BbrPxXJ9xNP/gYiqpLXYtYcneXeJEhvSY3388VdRR96292Ao8oLnklMon4V/U85cqXP0b4KmVbIW071zSwkbq6TkHmFt0sXWS1sJv7HIiefyAe9Or/UPQLNo5xByrtZgl+rj1c6zJR9O8EC5/IITtMSLAubO3D/fze3RGWgRjmCnW83NQWMtbkD3YIBr/KOO/3d4cZqxl2Qm/EhRoELNmkD4QuUcs5m6eLsyXRlr3uWzmB67ieCukF/C7GJGUl+NgPnMEsdLDfSypGN1Zn0/9w8Y0yyxA078P08x6 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > > As pointed out by Christian, this would optimize the "get all mappings > > backed by a specific BO from a given VM" use case. > > > > The question for me is, do other drivers than amdgpu commonly need this? > > I have no idea. > > > > > And what does amdgpu need this for? Maybe amdgpu does something we're > > not doing (yet)? > > Basically when we do a CS we need to make sure that the VM used by this > CS is up to date. For this we walk over the relocation list of BOs and > check the status of each BO+VM structure. > > This is done because we don't want to update all VMs at the same time, > but rather just those who needs the update. This seems like a legacy from GL and possibly older vulkan, going forward vulkan can't rely on passing lists of objects into the kernel due to things like buffer_device_address, I'm not sure we should optimise for this situation, and moving the tracking list into the drivers is going to mean having a bunch of drivers all having the same boilerplate, to do the same thing just so amdgpu can't avoid doing it. Now there might be some benchmark somewhere we can produce a benefit in this, and if there is then we should consider going this way for all drivers and not just allowing drivers to choose their own path here. > > > > Christian - I know you didn't ask for "do it the way amdgpu does", > > instead you voted for keeping it entirely driver specific. But I think > > everyone is pretty close and I'm still optimistic that we could just > > generalize this. > > Well, you should *not* necessarily do it like amdgpu does! Basically the > implementation in amdgpu was driven by requirements, e.g. we need that, > let's do it like this. > > It's perfectly possible that other requirements (e.g. focus on Vulkan) > lead to a completely different implementation. > > It's just that ideally I would like to have an implementation where I > can apply at least the basics to amdgpu as well. > I think we can still do that just either have an option to disable using the list internally in the gpuva or have the driver keep it's own tracking alongside, there may still be use cases where it can use the gpuva tracking instead of it's own. I don't think we should forklift what is pretty likely to be common code across every driver that uses this going forward just to benefit an amdgpu design decision for older stacks. Dave.