Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp3266708imc; Wed, 13 Mar 2019 13:12:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqz6ceTkaTKKcPDf+I8B0dPWdWKtBiKyMn+yWBMyRKtTYQx/gt0nVwGfG71R1hnx3MkCjTVf X-Received: by 2002:a62:bd09:: with SMTP id a9mr45162091pff.61.1552507934531; Wed, 13 Mar 2019 13:12:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552507934; cv=none; d=google.com; s=arc-20160816; b=MsuljMGNq4EmVRcFfZqbzcRycUzqsroGG+isp9xnbIgcSVraiHAKi64Cxr38wlvy5f 7WsTxfk07W0A12hb147z+yglFOGz5TbxLIML2XOPb65nYIMlq0d6EjBlYM2F3iPu0THH jFdcAZQFS6OjAPMLiLazl3evhDiTyo2VFflf+m37Q77ggH8wmJvMajRLqJGgGf2Si5xv XtNDanmIVEdyQ5bURVjqoWTlR2x3qFG9Ho7eoL057IvxwAo7KPzjnsy9OccCSYh1ihOf znxbIkYS7CQ440/KYuoLo/Nk/TU2uWiEyPBTCQKPNqK9jKShvC0EU2aBhYwUx7hzGyr2 3+EA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date:dmarc-filter :dkim-signature:dkim-signature; bh=RkyWDbQVcTQ8lP7Ovnf3KLndNDrPf5LtHsmLDPFF0Vs=; b=qgXjwizhHTNN3YJHleEilAJUtaHBJCYfl33W5LFoJjUNrOh1A7KyXqEwV6IociWRQc fb8lXSJ3FvDpFcuRvsHqYzEGpH3htvec/RmHIYzKZI6+0/vNE2yew88Z7gI7QpURzqr0 5N+K8y4yDxRKJYbOyK8uHZly4WpM8ANQRoLfmVFAAX7nQTieVYLwWubbSn2GhcIv162X lvyJrlqX1zBPbV9u49bBWfbs3Bucx6nnAmLRh2zD6GRwyHh14AM3ZtgYkOSCZ7I4+DUM dkLGhSGSwte2MDVf8H/N1iFecKq+mrza8IxWWUXnZj32I8hQso7hFAaV8SAjpYqMDaxI 88/w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=jPoN0OgG; dkim=pass header.i=@codeaurora.org header.s=default header.b=JeREGWIa; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p8si11449761plk.257.2019.03.13.13.11.58; Wed, 13 Mar 2019 13:12:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=jPoN0OgG; dkim=pass header.i=@codeaurora.org header.s=default header.b=JeREGWIa; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727168AbfCMULc (ORCPT + 99 others); Wed, 13 Mar 2019 16:11:32 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:60918 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726850AbfCMULb (ORCPT ); Wed, 13 Mar 2019 16:11:31 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 3D03B60386; Wed, 13 Mar 2019 20:11:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1552507890; bh=qK2c72XP1M3htngDtJG3/h4XZVvLv/+mUdau+/gcYdk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=jPoN0OgGzdCF0OUD3USY/BaKR9asBhwg4FiIpmbrbrLg/uEb+Hj9I9o7RpyEWKYt4 n+tXIn3AAU0WfDwYXm/m7793kjgcVO4npSoWh+bz8ZtGSMEk+GFt6jzNUisLsc3BBW rcO2W+ijZOjGKZMX3kcEFAY56Vl0bk4qCL2sSugk= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_INVALID,DKIM_SIGNED autolearn=no autolearn_force=no version=3.4.0 Received: from lmark-linux.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: lmark@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 9BDC960312; Wed, 13 Mar 2019 20:11:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1552507889; bh=qK2c72XP1M3htngDtJG3/h4XZVvLv/+mUdau+/gcYdk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=JeREGWIa6/Tk94IVW8ffE6OF4iK9plbLaSbEheV8PedM/Fr7fEFISh/uyHlXiQh7l Y4zY2vX+PVorZpAGPWNvmZWFJCBaYGIqjHck9BkI8RKU04s9T9hPq//BGsXPQfGRX7 5tTDlg9CaA6X4WBTTgEhIyS1nV/XFZYmcowXQ4uo= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 9BDC960312 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=lmark@codeaurora.org Date: Wed, 13 Mar 2019 13:11:28 -0700 (PDT) From: Liam Mark X-X-Sender: lmark@lmark-linux.qualcomm.com To: John Stultz cc: lkml , Laura Abbott , Benjamin Gaignard , Greg KH , Sumit Semwal , Brian Starkey , "Andrew F . Davis" , Chenbo Feng , Alistair Strachan , dri-devel Subject: Re: [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION) In-Reply-To: <1551819273-640-1-git-send-email-john.stultz@linaro.org> Message-ID: References: <1551819273-640-1-git-send-email-john.stultz@linaro.org> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 5 Mar 2019, John Stultz wrote: > Here is a initial RFC of the dma-buf heaps patchset Andrew and I > have been working on which tries to destage a fair chunk of ION > functionality. > > The patchset implements per-heap devices which can be opened > directly and then an ioctl is used to allocate a dmabuf from the > heap. > > The interface is similar, but much simpler then IONs, only > providing an ALLOC ioctl. > > Also, I've provided simple system and cma heaps. The system > heap in particular is missing the page-pool optimizations ION > had, but works well enough to validate the interface. > > I've booted and tested these patches with AOSP on the HiKey960 > using the kernel tree here: > https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap > > And the userspace changes here: > https://android-review.googlesource.com/c/device/linaro/hikey/+/909436 > > > Compared to ION, this patchset is missing the system-contig, > carveout and chunk heaps, as I don't have a device that uses > those, so I'm unable to do much useful validation there. > Additionally we have no upstream users of chunk or carveout, > and the system-contig has been deprecated in the common/andoid-* > kernels, so this should be ok. > > I've also removed the stats accounting for now, since it should > be implemented by the heaps themselves. > > Eventual TODOS: > * Reimplement page-pool for system heap (working on this) > * Add stats accounting to system/cma heaps > * Make the kselftest actually useful > * Add other heaps folks see as useful (would love to get > some help from actual carveout/chunk users)! We use a modified carveout heap for certain secure use cases. Although there would probably be some benefit in discssing how the dma-buf heap framework may want to support secure heaps in the future it is a large topic which I assume you don't want to tackle now. We don't have any non-secure carveout heap use cases but the client use case I have seen usually revolve around wanting large allocations to succeed very quickly. For example I have seen camera use cases which do very large allocations on camera bootup from the carveout heap, these allocations would come from the carveout heap and fallback to the system heap when the carveout heap was full. Actual non-secure carveout heap can perhaps provide more detail. > > That said, the main user-interface is shaping up and I wanted > to get some input on the device model (particularly from GreKH) > and any other API/ABI specific input. > > thanks > -john Thanks John and Andrew, it's great to see this effort to get this functionality out of staging. Since we are making some fundamental changes to how ION worked and since Android is likely also be the largest user of the dma-buf heaps framework I think it would be good to have a path to resolve the issues which are currently preventing commercial Android releases from moving to the upstream version of ION. I can understand if you don't necessarily want to put all/any of these changes into the dma-buf heaps framework as part of this series, but my hope is we can get the upstream community and the Android framework team to agree on what upstreamable changes to dma-buf heaps framework, and/or the Android framework, would be required in order for Android to move to the upstream dma-buf heaps framework for commercial devices. I don't mean to make this specific to Android, but my assumption is that many of the ION/dma-buf heaps issues which affect Android would likely affect other new large users of the dma-buf heaps framework, so if we resolve it for Android we would be helping these future users as well. And I do understand that some the issues facing Android may need to be resolved by making changes to Android framework. I think it would be helpful to try and get as much of this agreed upon as possible before the dma-buf heaps framework moves out of staging. As part of my review I will highlight some of the issues which would affect Android. In my comments I will apply them to the system heap since that is what Android currently uses for a lot of its use cases. I realize that this new framework provides more flexibility to heaps, so perhaps some of these issues can be solved by creating a new type of system heap which Android can use, but even if the solution involves creating a new system heap I would like to make sure that this "new" system heap is upstreamable. Liam Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project