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 B7327C64EC4 for ; Thu, 9 Mar 2023 09:12:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 24FBD6B0071; Thu, 9 Mar 2023 04:12:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 200BF6B0072; Thu, 9 Mar 2023 04:12:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C802280001; Thu, 9 Mar 2023 04:12:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id ECBB06B0071 for ; Thu, 9 Mar 2023 04:12:50 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B80DC1A02DA for ; Thu, 9 Mar 2023 09:12:50 +0000 (UTC) X-FDA: 80548794900.03.2FA46ED Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by imf12.hostedemail.com (Postfix) with ESMTP id A5C6B4001B for ; Thu, 9 Mar 2023 09:12:48 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=collabora.com header.s=mail header.b=HzW0uJ9f; spf=pass (imf12.hostedemail.com: domain of boris.brezillon@collabora.com designates 46.235.227.172 as permitted sender) smtp.mailfrom=boris.brezillon@collabora.com; dmarc=pass (policy=quarantine) header.from=collabora.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678353169; 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=jL/odltjbdDSY1YXt+0Kt+VlhlV8R4Q7DeQY+O4F7Cc=; b=x9xasfv9bc8KiGZ5+fFmBgyVg2IaxtGRIL5SyXSjissz837yFrGE+5na3nIN/3FaSPiPUG oIpI1b5QHB5ZQ7jQAFYdavFxWKbKerkPug14iMvM4FhKMmJlTl1oPj32bBUlgszpAextLq go6RBVqLfibwEAqUQaLbVgUNIVUngR4= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=collabora.com header.s=mail header.b=HzW0uJ9f; spf=pass (imf12.hostedemail.com: domain of boris.brezillon@collabora.com designates 46.235.227.172 as permitted sender) smtp.mailfrom=boris.brezillon@collabora.com; dmarc=pass (policy=quarantine) header.from=collabora.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678353169; a=rsa-sha256; cv=none; b=2YY4gFS0gpcsSxm/ss3v4eV4S12V0OwIGCG4H3px0Qr6KYwury+BAllR9IxldS1eQuMmIt bayLucix3TPttk41/PAi5sliZf2LjU9/8mGl2jQXlHuUUwhMHIQVhdcJFf2G6rVFn8429v 5Ce5IifJmPRcXxw9MKuS5JNdKsndzVg= Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:5cf4:84a1:2763:fe0d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by madras.collabora.co.uk (Postfix) with ESMTPSA id 47A556603007; Thu, 9 Mar 2023 09:12:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1678353166; bh=Qgp7ji/6xp0t3nAXwRde0Z0w/a3gnXKVlDede0CScv8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=HzW0uJ9f8N1SQuBc/+pQOt2agrSXDpaAelaubH9DNO+cAA3+eTo0e8e5pVKyH9RHT WjHH1nZUqjthdqoFk9uzfGzHA+kTS3p5seqHpSS17XoCPCQVu4zMWdwJq0+DqG2IWw /+M3b+ndbg7oWVBOZul8lkOQuMp8ueFAxGzHovB4L38BoVr3CZ7kdvk6mIubAFCoym xcvFDjFOTN+CwPZUMtLOd4JBD0rc1O3LTURQAiXU70ArxZLGZe2eDtybluy0Dcpbyy PJQBfJa5KEOvA7wBPxMl6tqc4cEepp90XeW4MEysa0axLFc8n9ROPoiBUVkVR9o1VX fjos71guF1Yiw== Date: Thu, 9 Mar 2023 10:12:43 +0100 From: Boris Brezillon To: Danilo Krummrich Cc: airlied@gmail.com, daniel@ffwll.ch, tzimmermann@suse.de, mripard@kernel.org, corbet@lwn.net, christian.koenig@amd.com, bskeggs@redhat.com, Liam.Howlett@oracle.com, matthew.brost@intel.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 Subject: Re: [PATCH drm-next v2 00/16] [RFC] DRM GPUVA Manager & Nouveau VM_BIND UAPI Message-ID: <20230309101243.1150506f@collabora.com> In-Reply-To: <20230217134422.14116-1-dakr@redhat.com> References: <20230217134422.14116-1-dakr@redhat.com> Organization: Collabora X-Mailer: Claws Mail 4.1.1 (GTK 3.24.36; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: f75at8gne3eg3z3gs3ury69mq3eop4bf X-Rspam-User: X-Rspamd-Queue-Id: A5C6B4001B X-Rspamd-Server: rspam06 X-HE-Tag: 1678353168-782168 X-HE-Meta: U2FsdGVkX1/2LJPOpg1YnBSvF9jijYuCjjYxHZpSHfoqnneEQAamctm8zch5F/BJflWcX3H/NTKmHSbUQAzDve0OglHmXGAQnOEmXOml1rlHL6a/ssQx280iGFwQMXC6EpMwAgf2wxialgbYPpwKle2losy3EPLZoDN7SjjkNeHeYlcuM0BfptzYLFJF5G453u7GR0kTOxBogZjKyqpEQgJmOEQ+0sEmpL/BzBwl68CgdWVpm94fQ4TdZc0b+jXlJ3d2BnH7GYuKYiS8ncJxjURrdYXIGbVUYtLDz5xsl2tPmOgvqwWa4T0cr8OXxryoA+VgrgR9SoXbjWwyfIdNpaImUuTebFa3AWfuBpar32rMAwSESF7AP1qsMY/ASPiEV6FIVX/3woDvSO0Xymj+/9B3JttkzRKtRWxZ9TYdcpiQ/dDdognN9+QDzt5hOasHagdcvX36xizk2qI9q15LvsrvmOgvm3VVgG+FkMfQivV7UZK2ifPodtTtepwcWDec9YIADCAXC0iJbcNiwv8l3msAMnzzWrpyb6ibvKPWKZsXh3rce3oRFE24HcbKhjNIv4GShVfe3v9FO/3gsaVIJv1cCNd8ne05oAlgc0xiIAVBmHt7rABCuWVafueH2JSxyKFauckdrrVjdVwcA57oafrlVtyRiuDboHnO/d4wlAyH0yn7occE+B1/vTvMjGQElpJnKqqYuLh97XlDz6QWCeMkIaBhHch4+Cg1/ktMfh2YGyZJq2bvxXKLz+Ijl+CJAQK/pu9tr/TyiK7nwGAswv4OFXVOufUpHIp2291A8yIyxIHNW+aYno33RPwr3gN+dzc6W6kddyVHCp39hqA8x4SpeLER9cvgzSSUNvENDDY9nPsr1C7LsyM5EKtG4yW7YY8W+Rw8xvihDnpUTVPlrx7Qvy7j0KGck0sRIhBcmRaDi0m38DWWTpiJvingas/IQeIbkz2HZOrAJh/tzyH +x5wvXg+ 6oxG+fLm8gWCIVS0aDg1CMZo189fH8olj0nTlOOQt3h9gvrl87la3Gxqd3LNZYDD8XccE1p6nrbuJnWDXhB7K+LVvKH/ELmdGnCr7HmwsOlLcc3gH3T+3TGLsRon4c/Q3Kx8kS9B9KH2QatfY/dgAYpB50SMRSMHGepO3QdEiicdMklgNMI9qZvryOpoZ/CsS587OEgjS+u+opFq8neoa+tazE4I8zDJDubaxyyqzY6vYWtpKzvwi1XHVSij6lZzsTR7278w46xRmNP3IQOx2QWaz82+3hGXutizf2/zXA4/+n+6Nb+zEefRrr4zIcPeg6ZxVTtpOqzl7ezWp4v/JYsNG3vNv4s2p5oh6 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: Hi Danilo, On Fri, 17 Feb 2023 14:44:06 +0100 Danilo Krummrich wrote: > Changes in V2: > ============== > Nouveau: > - Reworked the Nouveau VM_BIND UAPI to avoid memory allocations in fence > signalling critical sections. Updates to the VA space are split up in three > separate stages, where only the 2. stage executes in a fence signalling > critical section: > > 1. update the VA space, allocate new structures and page tables Sorry for the silly question, but I didn't find where the page tables pre-allocation happens. Mind pointing it to me? It's also unclear when this step happens. Is this at bind-job submission time, when the job is not necessarily ready to run, potentially waiting for other deps to be signaled. Or is it done when all deps are met, as an extra step before jumping to step 2. If that's the former, then I don't see how the VA space update can happen, since the bind-job might depend on other bind-jobs modifying the same portion of the VA space (unbind ops might lead to intermediate page table levels disappearing while we were waiting for deps). If it's the latter, I wonder why this is not considered as an allocation in the fence signaling path (for the bind-job out-fence to be signaled, you need these allocations to succeed, unless failing to allocate page-tables is considered like a HW misbehavior and the fence is signaled with an error in that case). Note that I'm not familiar at all with Nouveau or TTM, and it might be something that's solved by another component, or I'm just misunderstanding how the whole thing is supposed to work. This being said, I'd really like to implement a VM_BIND-like uAPI in pancsf using the gpuva_manager infra you're proposing here, so please bare with me :-). > 2. (un-)map the requested memory bindings > 3. free structures and page tables > > - Separated generic job scheduler code from specific job implementations. > - Separated the EXEC and VM_BIND implementation of the UAPI. > - Reworked the locking parts of the nvkm/vmm RAW interface, such that > (un-)map operations can be executed in fence signalling critical sections. > Regards, Boris