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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B9C10C433E0 for ; Mon, 22 Jun 2020 07:09:02 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 8F73325438 for ; Mon, 22 Jun 2020 07:09:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="GpTji/yh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8F73325438 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D1F8F6E598; Mon, 22 Jun 2020 07:07:52 +0000 (UTC) Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) by gabe.freedesktop.org (Postfix) with ESMTPS id 338DA6EC96 for ; Fri, 19 Jun 2020 11:39:37 +0000 (UTC) Received: by mail-qk1-x742.google.com with SMTP id w1so8562125qkw.5 for ; Fri, 19 Jun 2020 04:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=5lQCYSoi4FC78xGjLBeogrhLOaSlungd8A2lT6c416A=; b=GpTji/yhJTYfywss1k5am+JyELnNZlvvM8qP/Uyg3OD7x7MqDitwSWfgM3HPj0UhUM CmGRkgXfDHKjJbk/G94ThGo65HoXLKpYTHWId62kC64177gtGxTII+K1ZYz1wipOiAHJ eNgWeTmTaG/jDKlMWG2mJATpUK5rAwHHXT5FR/exkvaSA9MSXlfn3hlOUhTW2ZxS/H4F HEmI2H47vtMrMdfYBePKTzq7Q28TCNQpdwQLKytMyWVDkIDxh7YsNl1xg+jdzcXMR0cI rZrwuwfz+8JvRuJ/hZc0oTCMz+QMnazKQOTVrKsL2AkwHyGJfWycuxP+cVSimTbDO1fJ 9CVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=5lQCYSoi4FC78xGjLBeogrhLOaSlungd8A2lT6c416A=; b=YE67wOUxh6tJYjkNIN0Kr1jzUsBxJYY2wmtaYIui+ktBUWZ0wvRt2vRf1S9v+pCJQI 4zLuCIUu5K5l79TCd9DQuyaMoSsVNdSa8Tx+SzZCAzJVqVdiqhOOxKshfD/Y3UQh9Fka hRt/AfdMDwxQf74j7xYwqVQrqV13Y13XsSH1Di9t3Mr0Pk17xRYLQO4tbqqSSR3ZIs94 7/2ctP1s++BWpkgIVZZNwUt3C4F2dBrb0ky3WXV2xEUneP+iADIAaD6HI/IOXk5c6ljN 8Wjy7VGN0oVuHBjM+Rgb84QIoweqamTWeHQuZeWox4LWOM5e2oUYKTp5QNvzPb+5UBSF bJbg== X-Gm-Message-State: AOAM5323dB1JrAc7YQ8rblhfs2CcyQ7BVJuT9BVxv6Ajoqdrx9v6C/KU NifdVDi7j/Xu0OKSH0R08+e4Tw== X-Google-Smtp-Source: ABdhPJyvT5Fp9eB5e8a01kFzBtsDczKSLoT1L7Q5mintxsSice/gNXkvAdcFjnB+DRsdXJvj32xdRg== X-Received: by 2002:a37:6191:: with SMTP id v139mr2946071qkb.213.1592566776171; Fri, 19 Jun 2020 04:39:36 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-156-34-48-30.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.48.30]) by smtp.gmail.com with ESMTPSA id o6sm6016053qtd.59.2020.06.19.04.39.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Jun 2020 04:39:35 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.93) (envelope-from ) id 1jmFMs-00AiVa-OZ; Fri, 19 Jun 2020 08:39:34 -0300 Date: Fri, 19 Jun 2020 08:39:34 -0300 From: Jason Gunthorpe To: Daniel Vetter Subject: Re: [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations Message-ID: <20200619113934.GN6578@ziepe.ca> References: <20200604081224.863494-5-daniel.vetter@ffwll.ch> <20200611083430.GD20149@phenom.ffwll.local> <20200611141515.GW6578@ziepe.ca> <20200616120719.GL20149@phenom.ffwll.local> <20200617152835.GF6578@ziepe.ca> <20200618150051.GS20149@phenom.ffwll.local> <20200618172338.GM6578@ziepe.ca> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Mailman-Approved-At: Mon, 22 Jun 2020 07:07:47 +0000 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: linux-rdma , Thomas =?utf-8?B?SGVsbHN0csO2bSAoSW50ZWwp?= , LKML , DRI Development , Christian =?utf-8?B?S8O2bmln?= , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Thomas Hellstrom , amd-gfx list , Daniel Vetter , Mika Kuoppala , Intel Graphics Development , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, Jun 19, 2020 at 09:22:09AM +0200, Daniel Vetter wrote: > > As I've understood GPU that means you need to show that the commands > > associated with the buffer have completed. This is all local stuff > > within the driver, right? Why use fence (other than it already exists) > > Because that's the end-of-dma thing. And it's cross-driver for the > above reasons, e.g. > - device A renders some stuff. Userspace gets dma_fence A out of that > (well sync_file or one of the other uapi interfaces, but you get the > idea) > - userspace (across process or just different driver) issues more > rendering for device B, which depends upon the rendering done on > device A. So dma_fence A is an dependency and will block this dma > operation. Userspace (and the kernel) gets dma_fence B out of this > - because unfortunate reasons, the same rendering on device B also > needs a userptr buffer, which means that dma_fence B is also the one > that the mmu_range_notifier needs to wait on before it can tell core > mm that it can go ahead and release those pages I was afraid you'd say this - this is complete madness for other DMA devices to borrow the notifier hook of the first device! What if the first device is a page faulting device and doesn't call dma_fence?? It you are going to treat things this way then the mmu notifier really needs to be part of the some core DMA buf, and not randomly sprinkled in drivers But really this is what page pinning is supposed to be used for, the MM behavior when it blocks on a pinned page is less invasive than if it stalls inside a mmu notifier. You can mix it, use mmu notififers to keep track if the buffer is still live, but when you want to trigger DMA then pin the pages and keep them pinned until DMA is done. The pin protects things (well, fork is still a problem) Do not need to wait on dma_fence in notifiers. Jason _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel