From: Laura Abbott <labbott@redhat.com>
To: "Andrew F. Davis" <afd@ti.com>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Arve Hjønnevåg" <arve@android.com>
Cc: devel@driverdev.osuosl.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/14] Misc ION cleanups and adding unmapped heap
Date: Fri, 18 Jan 2019 12:19:38 -0800 [thread overview]
Message-ID: <f0b8e543-91db-997d-083a-08ae474795f1@redhat.com> (raw)
In-Reply-To: <f6d7f02d-791b-2095-4e94-8c323b6cefe9@ti.com>
On 1/16/19 8:05 AM, Andrew F. Davis wrote:
> On 1/15/19 12:58 PM, Laura Abbott wrote:
>> On 1/15/19 9:47 AM, Andrew F. Davis wrote:
>>> On 1/14/19 8:39 PM, Laura Abbott wrote:
>>>> On 1/11/19 10:05 AM, Andrew F. Davis wrote:
>>>>> Hello all,
>>>>>
>>>>> This is a set of (hopefully) non-controversial cleanups for the ION
>>>>> framework and current set of heaps. These were found as I start to
>>>>> familiarize myself with the framework to help in whatever way I
>>>>> can in getting all this up to the standards needed for de-staging.
>>>>>
>>>>> I would like to get some ideas of what is left to work on to get ION
>>>>> out of staging. Has there been some kind of agreement on what ION
>>>>> should
>>>>> eventually end up being? To me it looks like it is being whittled
>>>>> away at
>>>>> to it's most core functions. To me that is looking like being a DMA-BUF
>>>>> user-space front end, simply advertising available memory backings in a
>>>>> system and providing allocations as DMA-BUF handles. If this is the
>>>>> case
>>>>> then it looks close to being ready to me at least, but I would love to
>>>>> hear any other opinions and concerns.
>>>>>
>>>>
>>>> Yes, at this point the only functionality that people are really
>>>> depending on is the ability to allocate a dma_buf easily from userspace.
>>>>
>>>>> Back to this patchset, the last patch may be a bit different than the
>>>>> others, it adds an unmapped heaps type and creation helper. I wanted to
>>>>> get this in to show off another heap type and maybe some issues we may
>>>>> have with the current ION framework. The unmapped heap is used when the
>>>>> backing memory should not (or cannot) be touched. Currently this kind
>>>>> of heap is used for firewalled secure memory that can be allocated like
>>>>> normal heap memory but only used by secure devices (OP-TEE, crypto HW,
>>>>> etc). It is basically just copied from the "carveout" heap type with
>>>>> the
>>>>> only difference being it is not mappable to userspace and we do not
>>>>> clear
>>>>> the memory (as we should not map it either). So should this really be a
>>>>> new heap type? Or maybe advertised as a carveout heap but with an
>>>>> additional allocation flag? Perhaps we do away with "types" altogether
>>>>> and just have flags, coherent/non-coherent, mapped/unmapped, etc.
>>>>>
>>>>> Maybe more thinking will be needed afterall..
>>>>>
>>>>
>>>> So the cleanup looks okay (I need to finish reviewing) but I'm not a
>>>> fan of adding another heaptype without solving the problem of adding
>>>> some sort of devicetree binding or other method of allocating and
>>>> placing Ion heaps. That plus uncached buffers are one of the big
>>>> open problems that need to be solved for destaging Ion. See
>>>> https://lore.kernel.org/lkml/20181120164636.jcw7li2uaa3cmwc3@DESKTOP-E1NTVVP.localdomain/
>>>>
>>>>
>>>> for some background on that problem.
>>>>
>>>
>>> I'm under the impression that adding heaps like carveouts/chunk will be
>>> rather system specific and so do not lend themselves well to a universal
>>> DT style exporter. For instance a carveout memory space can be reported
>>> by a device at runtime, then the driver managing that device should go
>>> and use the carveout heap helpers to export that heap. If this is the
>>> case then I'm not sure it is a problem for the ION core framework to
>>> solve, but rather the users of it to figure out how best to create the
>>> various heaps. All Ion needs to do is allow exporting and advertising
>>> them IMHO.
>>>
>>
>> I think it is a problem for the Ion core framework to take care of.
>> Ion is useless if you don't actually have the heaps. Nobody has
>> actually gotten a full Ion solution end-to-end with a carveout heap
>> working in mainline because any proposals have been rejected. I think
>> we need at least one example in mainline of how creating a carveout
>> heap would work.
>
> In our evil vendor trees we have several examples. The issue being that
> Ion is still staging and attempts for generic DT heap definitions
> haven't seemed to go so well. So for now we just keep it specific to our
> platforms until upstream makes a direction decision.
>
Yeah, it's been a bit of a chicken and egg in that this has been
blocking Ion getting out of staging but we don't actually have
in-tree users because it's still in staging.
>>
>>> Thanks for the background thread link, I've been looking for some info
>>> on current status of all this and "ion" is a bit hard to search the
>>> lists for. The core reason for posting this cleanup series is to throw
>>> my hat into the ring of all this Ion work and start getting familiar
>>> with the pending issues. The last two patches are not all that important
>>> to get in right now.
>>>
>>> In that thread you linked above, it seems we may have arrived at a
>>> similar problem for different reasons. I think the root issue is the Ion
>>> core makes too many assumptions about the heap memory. My proposal would
>>> be to allow the heap exporters more control over the DMA-BUF ops, maybe
>>> even going as far as letting them provide their own complete struct
>>> dma_buf_ops.
>>>
>>> Let me give an example where I think this is going to be useful. We have
>>> the classic constraint solving problem on our SoCs. Our SoCs are full of
>>> various coherent and non-coherent devices, some require contiguous
>>> memory allocations, others have in-line IOMMUs so can operate on
>>> non-contiguous, etc..
>>>
>>> DMA-BUF has a solution designed in for this we can use, namely
>>> allocation at map time after all the attachments have come in. The
>>> checking of each attached device to find the right backing memory is
>>> something the DMA-BUF exporter has to do, and so this SoC specific logic
>>> would have to be added to each exporting framework (DRM, V4L2, etc),
>>> unless we have one unified system exporter everyone uses, Ion.
>>>
>>
>> That's how dmabuf is supposed to work in theory but in practice we
>> also have the case of userspace allocates memory, mmaps, and then
>> a device attaches to it. The issue is we end up having to do work
>> and make decisions before all devices are actually attached.
>>
>
> That just seems wrong, DMA-BUF should be used for, well, DMA-able
> buffers.. Userspace should not be using these buffers without devices
> attached, otherwise why not use a regular buffer. If you need to fill
> the buffer then you should attach/map it first so the DMA-BUF exporter
> can pick the appropriate backing memory first.
>
> Maybe a couple more rules on the ordering of DMA-BUF operations are
> needed to prevent having to deal with all these non-useful permutations.
>
> Sumit? ^^
>
I'd love to just say "don't do that" but it's existing userspace
behavior and it's really hard to change that.
>>> Then each system can define one (maybe typeless) heap, the correct
>>> backing type is system specific anyway, so let the system specific
>>> backing logic in the unified system exporter heap handle picking that.
>>> To allow that heaps need direct control of dma_buf_ops.
>>>
>>> Direct heap control of dma_buf_ops also fixes the cache/non-cache issue,
>>> and my unmapped memory issue, each heap type handles the quirks of its
>>> backing storage in its own way, instead of trying to find some one size
>>> fits all memory operations like we are doing now.
>>>
>>
>> I don't think this is an issue of one-size fits all. We have flags
>> to differentiate between cached and uncached paths, the issue is
>> that doing the synchronization for uncached buffers is difficult.
>>
>
> It is difficult, hence why letting an uncached heap exporter do all the
> heavy work, instead of trying to deal with all these cases in the Ion
> core framework.
>
>> I'm just not sure how an extra set of dma_buf ops actually solves
>> the problem of needing to synchronize alias mappings.
>>
>
> It doesn't solve it, it just moves the work out of the framework. There
> are going to be a lot more interesting problems than this with some
> types heaps we will have in the future, dealing with all the logic in
> the framework core is not going to scale.
>
That is a good point. My immediate concern though is getting Ion out
of staging. If the per heap dma_buf ops will help with that I'd
certainly like to see them.
Thanks,
Laura
> Thanks,
> Andrew
>
>> Thanks,
>> Laura
>>
>>> We can provide helpers for the simple heap types still, but with this
>>> much of the heavy lifting moves out of the Ion core framework making it
>>> much more simple, something I think it will need for de-staging.
>>>
>>> Anyway, I might be completely off base in my direction here, just let me
>>> know :)
>>>
>>
next prev parent reply other threads:[~2019-01-18 20:19 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-11 18:05 [PATCH 00/14] Misc ION cleanups and adding unmapped heap Andrew F. Davis
2019-01-11 18:05 ` [PATCH 01/14] staging: android: ion: Add proper header information Andrew F. Davis
2019-01-11 18:05 ` [PATCH 02/14] staging: android: ion: Remove empty ion_ioctl_dir() function Andrew F. Davis
2019-01-11 18:05 ` [PATCH 03/14] staging: android: ion: Merge ion-ioctl.c into ion.c Andrew F. Davis
2019-01-11 18:05 ` [PATCH 04/14] staging: android: ion: Remove leftover comment Andrew F. Davis
2019-01-11 18:05 ` [PATCH 05/14] staging: android: ion: Remove struct ion_platform_heap Andrew F. Davis
2019-01-11 18:05 ` [PATCH 06/14] staging: android: ion: Fixup some white-space issues Andrew F. Davis
2019-01-11 18:05 ` [PATCH 07/14] staging: android: ion: Sync comment docs with struct ion_buffer Andrew F. Davis
2019-01-11 18:05 ` [PATCH 08/14] staging: android: ion: Remove base from ion_carveout_heap Andrew F. Davis
2019-01-11 18:05 ` [PATCH 09/14] staging: android: ion: Remove base from ion_chunk_heap Andrew F. Davis
2019-01-11 18:05 ` [PATCH 10/14] staging: android: ion: Remove unused headers Andrew F. Davis
2019-01-11 18:05 ` [PATCH 11/14] staging: android: ion: Allow heap name to be null Andrew F. Davis
2019-01-16 15:28 ` Brian Starkey
2019-01-16 17:12 ` Andrew F. Davis
2019-01-18 19:53 ` Laura Abbott
2019-01-21 14:30 ` Andrew F. Davis
2019-01-11 18:05 ` [PATCH 12/14] staging: android: ion: Declare helpers for carveout and chunk heaps Andrew F. Davis
2019-01-18 9:59 ` Greg Kroah-Hartman
2019-01-18 16:09 ` Andrew F. Davis
2019-01-18 19:54 ` Laura Abbott
2019-01-11 18:05 ` [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap Andrew F. Davis
2019-01-14 17:13 ` Liam Mark
2019-01-15 15:44 ` Andrew F. Davis
2019-01-15 17:45 ` Liam Mark
2019-01-15 18:38 ` Andrew F. Davis
2019-01-15 18:40 ` Andrew F. Davis
2019-01-16 15:19 ` Brian Starkey
2019-01-16 17:05 ` Andrew F. Davis
2019-01-16 22:54 ` Liam Mark
2019-01-17 16:25 ` Andrew F. Davis
2019-01-18 1:11 ` Liam Mark
2019-01-18 17:16 ` Andrew F. Davis
2019-01-21 11:22 ` Brian Starkey
2019-01-21 21:21 ` Andrew F. Davis
2019-01-22 17:33 ` Sumit Semwal
2019-01-23 16:51 ` Andrew F. Davis
2019-01-23 17:11 ` Brian Starkey
2019-01-24 16:04 ` Andrew F. Davis
2019-01-24 16:44 ` Brian Starkey
2019-02-19 21:37 ` Laura Abbott
[not found] ` <CAO_48GHZPkE8Or_dB6CVMi5Jv5eufE_Z36MT7ztJwTqTzkTpKA@mail.gmail.com>
2019-01-23 17:09 ` Andrew F. Davis
2019-01-22 22:56 ` Liam Mark
2019-01-21 20:11 ` Liam Mark
2019-01-15 19:05 ` Laura Abbott
2019-01-16 16:17 ` Andrew F. Davis
2019-01-16 22:48 ` Liam Mark
2019-01-17 16:13 ` Andrew F. Davis
2019-01-18 1:04 ` Liam Mark
2019-01-18 16:50 ` Andrew F. Davis
2019-01-18 21:43 ` Liam Mark
2019-01-21 15:15 ` Andrew F. Davis
2019-01-21 20:04 ` Liam Mark
2019-01-18 20:31 ` Laura Abbott
2019-01-18 20:43 ` Andrew F. Davis
2019-01-18 20:46 ` Laura Abbott
2019-01-19 10:11 ` Christoph Hellwig
2019-01-17 9:02 ` Christoph Hellwig
2019-01-11 18:05 ` [PATCH 14/14] staging: android: ion: Add UNMAPPED heap type and helper Andrew F. Davis
2019-01-15 2:32 ` Laura Abbott
2019-01-15 15:58 ` Andrew F. Davis
2019-01-15 18:43 ` Laura Abbott
2019-01-15 19:11 ` Laura Abbott
2019-01-16 16:18 ` Andrew F. Davis
2019-01-15 2:39 ` [PATCH 00/14] Misc ION cleanups and adding unmapped heap Laura Abbott
2019-01-15 17:47 ` Andrew F. Davis
2019-01-15 18:58 ` Laura Abbott
2019-01-16 16:05 ` Andrew F. Davis
2019-01-18 20:19 ` Laura Abbott [this message]
2019-01-21 14:58 ` Andrew F. Davis
2019-01-18 9:56 ` Greg Kroah-Hartman
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f0b8e543-91db-997d-083a-08ae474795f1@redhat.com \
--to=labbott@redhat.com \
--cc=afd@ti.com \
--cc=arve@android.com \
--cc=devel@driverdev.osuosl.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sumit.semwal@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).