From: Liam Mark <firstname.lastname@example.org>
To: John Stultz <email@example.com>
Cc: lkml <firstname.lastname@example.org>,
Laura Abbott <email@example.com>,
Benjamin Gaignard <firstname.lastname@example.org>,
Greg KH <email@example.com>,
Sumit Semwal <firstname.lastname@example.org>,
Brian Starkey <Brian.Starkey@arm.com>,
"Andrew F . Davis" <email@example.com>, Chenbo Feng <firstname.lastname@example.org>,
Alistair Strachan <email@example.com>,
Subject: Re: [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION)
Date: Wed, 13 Mar 2019 13:11:28 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.firstname.lastname@example.org> (raw)
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
> The patchset implements per-heap devices which can be opened
> directly and then an ioctl is used to allocate a dmabuf from the
> 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:
> And the userspace changes here:
> 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
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 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
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.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2019-03-13 20:11 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-05 20:54 [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION) John Stultz
2019-03-05 20:54 ` [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework John Stultz
2019-03-06 16:12 ` Benjamin Gaignard
2019-03-06 16:57 ` John Stultz
2019-03-15 8:55 ` Christoph Hellwig
2019-03-06 16:27 ` Andrew F. Davis
2019-03-06 19:03 ` John Stultz
2019-03-06 21:45 ` Andrew F. Davis
2019-03-15 8:54 ` Christoph Hellwig
2019-03-15 20:24 ` Andrew F. Davis
2019-03-15 20:18 ` Laura Abbott
2019-03-15 20:49 ` Andrew F. Davis
2019-03-15 21:29 ` John Stultz
2019-03-15 22:44 ` Laura Abbott
2019-03-18 4:38 ` Sumit Semwal
2019-03-18 4:41 ` Sumit Semwal
2019-03-19 12:08 ` Brian Starkey
2019-03-19 15:24 ` Andrew F. Davis
2019-03-21 21:16 ` John Stultz
2019-03-27 14:53 ` Greg KH
2019-03-28 6:09 ` John Stultz
2019-03-05 20:54 ` [RFC][PATCH 2/5 v2] dma-buf: heaps: Add heap helpers John Stultz
2019-03-13 20:18 ` Liam Mark
2019-03-13 21:48 ` Andrew F. Davis
2019-03-13 22:57 ` Liam Mark
2019-03-13 23:42 ` Andrew F. Davis
2019-03-15 9:06 ` Christoph Hellwig
2019-03-19 15:03 ` Andrew F. Davis
2019-03-21 20:01 ` John Stultz
2019-03-19 14:26 ` Brian Starkey
2019-03-21 20:11 ` John Stultz
2019-03-21 20:35 ` Andrew F. Davis
2019-03-21 20:43 ` Andrew F. Davis
2019-03-05 20:54 ` [RFC][PATCH 3/5 v2] dma-buf: heaps: Add system heap to dmabuf heaps John Stultz
2019-03-06 16:01 ` Benjamin Gaignard
2019-03-11 5:48 ` John Stultz
2019-03-13 20:20 ` Liam Mark
2019-03-13 22:49 ` John Stultz
2019-03-15 9:06 ` Christoph Hellwig
2019-03-05 20:54 ` [RFC][PATCH 4/5 v2] dma-buf: heaps: Add CMA heap to dmabuf heapss John Stultz
2019-03-06 16:05 ` Benjamin Gaignard
2019-03-21 20:15 ` John Stultz
2019-03-15 9:06 ` Christoph Hellwig
2019-03-15 20:08 ` John Stultz
2019-03-19 14:53 ` Brian Starkey
2019-03-05 20:54 ` [RFC][PATCH 5/5 v2] kselftests: Add dma-heap test John Stultz
2019-03-06 16:14 ` Benjamin Gaignard
2019-03-06 16:35 ` Andrew F. Davis
2019-03-06 18:19 ` John Stultz
2019-03-06 18:32 ` Andrew F. Davis
2019-03-06 17:01 ` John Stultz
2019-03-15 20:07 ` Laura Abbott
2019-03-15 20:13 ` John Stultz
2019-03-15 20:49 ` Laura Abbott
2019-03-13 20:23 ` Liam Mark
2019-03-13 20:11 ` Liam Mark [this message]
2019-03-13 22:30 ` [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION) John Stultz
2019-03-13 23:29 ` Liam Mark
2019-03-19 16:54 ` Benjamin Gaignard
2019-03-19 16:59 ` Andrew F. Davis
2019-03-19 21:58 ` Rob Clark
2019-03-19 22:36 ` John Stultz
2019-03-20 9:16 ` Benjamin Gaignard
2019-03-20 14:44 ` Andrew F. Davis
2019-03-20 15:59 ` Benjamin Gaignard
2019-03-20 16:11 ` John Stultz
2019-03-15 20:34 ` Laura Abbott
2019-03-15 23:15 ` Jerome Glisse
2019-03-16 0:16 ` John Stultz
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).