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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 32F59C0650F for ; Thu, 8 Aug 2019 11:58:25 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 04B8D2173C for ; Thu, 8 Aug 2019 11:58:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="OwukTuGX"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="RtAidmmq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 04B8D2173C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Ul6jKWj2ixg/vhV3ZHmDafxyVecf1zXL3xEXeWCoyfo=; b=OwukTuGXWX7jQm xgXe2KKaVtWE1Vg9XuNTfyI5uYd+UwnX9DOM0qBwuCfznaBD7PwNoL8czLM5k8pWNygmy+ufPvI+6 ErQeo3Rd8mQ2CM3ipvNuJjc7480yjN9ZF5L6wrRtyKBGGMyQA726sMcAm87MF+ZAS7uKIxq/HJmff n2c6N62UF8FMKScWRp1taGR49KLJqPcs5ckF2SRTvp11KLVuipyt9zWzcgz2AzILOQr9qj4/Upqnx 5P5AcPl/J21VIpc+QxroK5YLjUZDEx8Uf1R20FT1DWHpR0kgaJA1t63ABhF+IFR0aBpw4/RYxunhe cudQ0/0fgrvlRZUoUq5g==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hvh3h-0007Fx-80; Thu, 08 Aug 2019 11:58:17 +0000 Received: from mail-ed1-x541.google.com ([2a00:1450:4864:20::541]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hvh3d-0007FB-80 for linux-arm-kernel@lists.infradead.org; Thu, 08 Aug 2019 11:58:14 +0000 Received: by mail-ed1-x541.google.com with SMTP id k8so90417136edr.11 for ; Thu, 08 Aug 2019 04:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=mhO+hgPBV+VLoBe4FkLMr7mrrkAfMlf4RoVKrIDPI8U=; b=RtAidmmqIIva4EOO0Ms7+a5chcAGS7/yKnSnvq39J/g3vx0a+JVWFjbQb+KC211qET loJwSr4SQzfx6oDGn37n+bXY3zmhi4MoYZmqdkOMwoDDYZqyyWd+XO5simV3pT/raCp2 F90mSqfkHi4PKIqiR/ORYKx+1b/TTuD7ygW1Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=mhO+hgPBV+VLoBe4FkLMr7mrrkAfMlf4RoVKrIDPI8U=; b=CeXwbJgXQzUtHWdQ3LKwPQzk7qDToBwesBsqZxAqT2ZLQdyCH7C3pShK6ZkI3btxqn DvJvOluetGUNOtlxIEfuBA2OMC5pK3kkwqE+PydlDVymDWGFerfeANuEJIYsXMz7VJ5n oX83f7KAp3huxIUhq00uAgWIPfScgCWksWZ8qlLsiQnjCPL53OJC9AOJnQRJU+R60Wb1 qta2fEKeD8Smi+WsroluIJVyK993uAjxGAiPjmlHzzs4/+MUz2gr8RuIWxlqmxt5GByq tLkgJFHMo61FG43/FNw4OFBk3nPwMW2bjtY8iXZ5su6G20TZYlI3LjDfz/Id95bQbrmz zUwA== X-Gm-Message-State: APjAAAXInW2MFXIlSXEQ728NI9Ny7leaj62Bpcm2DmzNRBZtByRAIPUM 9SSJ+gaBgFqQ5snxJChZB9lGkQ== X-Google-Smtp-Source: APXvYqw9uraKM7qWqZW0Dg09fB6Nm02V7GB56xhaxehSuiymr4qKYwchHDPZ5RvXrNR5LEVxCZukiQ== X-Received: by 2002:a17:906:ccc3:: with SMTP id ot3mr13167350ejb.113.1565265491478; Thu, 08 Aug 2019 04:58:11 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:569e:0:3106:d637:d723:e855]) by smtp.gmail.com with ESMTPSA id d12sm21361343edp.16.2019.08.08.04.58.09 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 08 Aug 2019 04:58:10 -0700 (PDT) Date: Thu, 8 Aug 2019 13:58:08 +0200 From: Daniel Vetter To: Christoph Hellwig Subject: Re: [PATCH 1/2] drm: add cache support for arm64 Message-ID: <20190808115808.GN7444@phenom.ffwll.local> Mail-Followup-To: Christoph Hellwig , Rob Clark , Rob Clark , dri-devel , Catalin Marinas , Will Deacon , Maarten Lankhorst , Maxime Ripard , Sean Paul , David Airlie , Allison Randal , Greg Kroah-Hartman , Thomas Gleixner , Linux ARM , LKML References: <20190805211451.20176-1-robdclark@gmail.com> <20190806084821.GA17129@lst.de> <20190806155044.GC25050@lst.de> <20190807062545.GF6627@lst.de> <20190808095506.GA32621@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190808095506.GA32621@lst.de> X-Operating-System: Linux phenom 4.19.0-5-amd64 User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190808_045813_348041_EF9D5A6A X-CRM114-Status: GOOD ( 19.68 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Rob Clark , Maxime Ripard , Catalin Marinas , David Airlie , Maarten Lankhorst , LKML , dri-devel , Sean Paul , Rob Clark , Linux ARM , Daniel Vetter , Greg Kroah-Hartman , Thomas Gleixner , Will Deacon , Allison Randal Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Aug 08, 2019 at 11:55:06AM +0200, Christoph Hellwig wrote: > On Wed, Aug 07, 2019 at 10:48:56AM +0200, Daniel Vetter wrote: > > > other drm drivers how do they guarantee addressability without an > > > iommu?) > > > > We use shmem to get at swappable pages. We generally just assume that > > the gpu can get at those pages, but things fall apart in fun ways: > > - some setups somehow inject bounce buffers. Some drivers just give > > up, others try to allocate a pool of pages with dma_alloc_coherent. > > - some devices are misdesigned and can't access as much as the cpu. We > > allocate using GFP_DMA32 to fix that. > > Well, for shmem you can't really call allocators directly, right? We can pass gfp flags to shmem_read_mapping_page_gfp, which is just about enough for the 2 cases on intel platforms where the gpu can only access 4G, but the cpu has way more. > One thing I have in my pipeline is a dma_alloc_pages API that allocates > pages that are guaranteed to be addressably by the device or otherwise > fail. But that doesn't really help with the shmem fs. Yeah, the other drivers where the shmem gfp trick doesn't work copy back&forth between the dma-able pages and the shmem swappable pages as needed in their shrinker/allocation code. I guess ideal would be if we could fuse the custom allocator somehow directly into shmem. Otoh once you start thrashing beyond system memory for gfx workloads it's pretty hopeless anyway, and speed doesn't really matter anymore. > > Also modern gpu apis pretty much assume you can malloc() and then use > > that directly with the gpu. > > Which is fine as long as the GPU itself supports full 64-bit addressing > (or always sits behind an iommu), and the platform doesn't impose > addressing limit, which unfortunately some that are shipped right now > still do :( Yes, the userspace api people in khronos are occasionally a bit optimistic :-) > But userspace malloc really means dma_map_* anyway, so not really > relevant for memory allocations. It does tie in, since we'll want a dma_map which fails if a direct mapping isn't possible. It also helps the driver code a lot if we could use the same low-level flushing functions between our own memory (whatever that is) and anon pages from malloc. And in all the cases if it's not possible, we want a failure, not elaborate attempts at hiding the differences between all possible architectures out there. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel