[Linaro-mm-sig] Memory Management Discussion

[Jesse Barker]

The update to the wiki based upon the ELC talk has those 3, but breaks
up the mapping into separate in-kernel and user-space mapping issues.
Oh, and in the discussion, I think we were referring to buffer flows
as configuration, but it seems the same to me.  At any rate, I think
we've captured the ideas and some of the mechanisms that address them
(or attempt to).  Could use more detail, though.

cheers,
Jesse

On Wed, Apr 20, 2011 at 2:24 PM, Zach Pfeffer <zach.pfeffer at linaro.org> wrote:
> That's true.
>
> I think there's some value in splitting the discussion up into 3 areas:
>
> Allocation
> Mapping
> Buffer flows
>
> There seems to be a general design disconnect between the way Linux
> deals with buffer mapping (one mapper at a time, buffers are mapped
> and unmapped as they flow through the system) and the way users
> actually want things to work (sharing a global buffer that one entity
> writes to and another reads without unmapping each time).
>
> Perhaps there's a solution that will give users the allusion of shared
> mappings while ensuring correctness if those mappings are different
> (something on-demand perhaps).
>
> -Zach
>
> On 20 April 2011 10:13, Jordan Crouse <jcrouse at codeaurora.org> wrote:
>> On 04/19/2011 10:12 PM, Zach Pfeffer wrote:
>>>
>>> Speaking of Graphics and Multimedia - we may want to discuss IOMMU
>>> APIs and distributed memory management. These devices are becoming
>>> more prevalent and having a standard way of working with them would be
>>> useful.
>>>
>>> I did a little of this work at Qualcomm and pushed some soundly
>>> rejected patches to the kernel, see "mm: iommu: An API to unify IOMMU,
>>> CPU and device memory management."
>>>
>>> -Zach
>>
>> As we talked during the meeting at ELC, IOMMU is important, but I think that
>> there
>> is broad agreement to consolidate (eventually) on the standard APIs.  I
>> still think
>> that the memory allocation problem is the more interesting one because it
>> affects
>> everybody equally, MMU or not.  Not that I want to shut down debate or
>> anything,
>> I just don't want to distract us from the larger problem that we face.
>>
>> Jordan
>>
>>> On 19 April 2011 20:52, Clark, Rob<rob at ti.com>  wrote:
>>>>
>>>> On Mon, Apr 18, 2011 at 9:45 AM, Sree Kumar<sreeon at gmail.com>  wrote:
>>>>>
>>>>> Thanks Jesse for initiating the mailing list.
>>>>>
>>>>> We need to address the requirements of Graphics and Multimedia
>>>>> Accelerators
>>>>> (IPs).
>>>>> What we really need is a permanent solution (at upstream) which
>>>>> accommodates
>>>>> the following requirements and conforms to Graphics and Multimedia use
>>>>> cases.
>>>>>
>>>>> 1.Mechanism to map/unmap the memory. Some of the IPs’ have the ability
>>>>> to
>>>>> address virtual memory and some can address only physically contiguous
>>>>> address space. We need to address both these cases.
>>>>> 2.Mechanism to allocate and release memory.
>>>>> 3.Method to share the memory (ZERO copy is a MUST for better
>>>>> performance)
>>>>> between different device drivers (example output of camera to multimedia
>>>>> encoder).
>>>>> 4.Method to share the memory with different processes in userspace. The
>>>>> sharing mechanism should include built-in security features.
>>>>>
>>>>> Are there any special requirements from V4L or DRM perspectives?
>>>>
>>>>  From DRI perspective.. I guess the global buffer name is restricted to
>>>> a 4 byte integer, unless you change the DRI proto..
>>>>
>>>> Authentication hooks for the driver (on x11 driver side) are for a
>>>> single authentication covering all buffers shared between client and
>>>> server, and is done by 4 byte token exchange between client and
>>>> server.  I've not had time yet to look more closely at the
>>>> authentication aspect of ION.
>>>>
>>>> Those are just things off the top of my head, hopefully someone else
>>>> from X11 world chimes in with whatever else I missed.  But I guess
>>>> most important thing is whether or not it can fit within existing DRI
>>>> protocol.  If it does, then the drivers on client and server side
>>>> could use whatever..
>>>>
>>>> BR,
>>>> -R
>>>>
>>>>
>>>>> Thanks,
>>>>> Sree
>>>>>
>>>>> _______________________________________________
>>>>> Linaro-mm-sig mailing list
>>>>> Linaro-mm-sig at lists.linaro.org
>>>>> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Linaro-mm-sig mailing list
>>>> Linaro-mm-sig at lists.linaro.org
>>>> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>>>>
>>>
>>> _______________________________________________
>>> Linaro-mm-sig mailing list
>>> Linaro-mm-sig at lists.linaro.org
>>> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>>
>>
>> --
>> Jordan Crouse
>> Qualcomm Innovation Center
>> Qualcomm Innovation Center is a member of Code Aurora Forum
>>
>
> _______________________________________________
> Linaro-mm-sig mailing list
> Linaro-mm-sig at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>