Hi,
At LPC, I proposed a moratorium on new Ion features because of issues preventing Ion ever moving out of staging. Among other problems, the Ion caching model hasn't made much progress to a solution that is widely accepted and there are still problems with devicetree support. There were no strong objections to this proposal so I propose continuing with a moratorium for at least the next 6 months to a year to actually work on a new architecture. If this hasn't made much progress by then I plan to hand off Ion to someone else to try other approaches.
There's been some discussion about a Unix Device Memory Allocator https://github.com/cubanismo/allocator . Ideally, this would be a complete replacement for Ion. This means capturing Ion or Ion-like requirements. The current proposal mostly focuses on userspace requirements and assumes Ion is just acting as an enumerator of various memory to allocate. This is a good direction. Ideally some of the Ion kernel code could be leveraged for a 'generic device memory allocator'. This device allocator should also be support use cases such as the SMAF (secure memory allocation framework) which has also been a work in progress.
One of the big open problems, as mentioned above, is the caching model. Specifying an uncached buffer at allocation time requires doing cache operations outside of the DMA framework which makes a bunch of maintainers unhappy. None of the arguments I've given for justification have really stuck which is a good sign that Ion should probably not be doing cache operations. If we ignore the Ion page pooling feature, this could be fixed by requiring that drivers call dma_buf_map and calling dma_map there. This gets tricker when drivers want to call mmap from userspace before passing the buffer down to ensure coherency. This model will need some more thought and possibly integration with Android.
I'd like to keep using linaro-mm-sig as a mailing list for Ion discussion as well as drivers-devel. If it would help to have another place for tracking/discussion I can see about setting that up as well.
Thanks, Laura
Hi Laura,
Thanks for what you are doing on ION. As soon that will be ok I will submit again the driver for sti platform.
After reading your mail I have the feeling that solves cache, devicetree and legacy support problems will be difficult.
Since "Unix Device Memory Allocator" claims that it will solve memory requirements for us, would it not be more simple to write "standalone" drivers for each memory type (CMA, carveout, etc..) ? What I have in mind is a set of kernel allocators sharing a minimum of code like some ioctl and /dev/allocator/xxx
The drawback is that we have to start something for scratch but could it complementary to what you are doing?
Regards, Benjamin
2016-11-18 22:07 GMT+01:00 Laura Abbott labbott@redhat.com:
Hi,
At LPC, I proposed a moratorium on new Ion features because of issues preventing Ion ever moving out of staging. Among other problems, the Ion caching model hasn't made much progress to a solution that is widely accepted and there are still problems with devicetree support. There were no strong objections to this proposal so I propose continuing with a moratorium for at least the next 6 months to a year to actually work on a new architecture. If this hasn't made much progress by then I plan to hand off Ion to someone else to try other approaches.
There's been some discussion about a Unix Device Memory Allocator https://github.com/cubanismo/allocator . Ideally, this would be a complete replacement for Ion. This means capturing Ion or Ion-like requirements. The current proposal mostly focuses on userspace requirements and assumes Ion is just acting as an enumerator of various memory to allocate. This is a good direction. Ideally some of the Ion kernel code could be leveraged for a 'generic device memory allocator'. This device allocator should also be support use cases such as the SMAF (secure memory allocation framework) which has also been a work in progress.
One of the big open problems, as mentioned above, is the caching model. Specifying an uncached buffer at allocation time requires doing cache operations outside of the DMA framework which makes a bunch of maintainers unhappy. None of the arguments I've given for justification have really stuck which is a good sign that Ion should probably not be doing cache operations. If we ignore the Ion page pooling feature, this could be fixed by requiring that drivers call dma_buf_map and calling dma_map there. This gets tricker when drivers want to call mmap from userspace before passing the buffer down to ensure coherency. This model will need some more thought and possibly integration with Android.
I'd like to keep using linaro-mm-sig as a mailing list for Ion discussion as well as drivers-devel. If it would help to have another place for tracking/discussion I can see about setting that up as well.
Thanks, Laura
Linaro-mm-sig mailing list Linaro-mm-sig@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-mm-sig
On 11/25/2016 04:30 AM, Benjamin Gaignard wrote:
Hi Laura,
Thanks for what you are doing on ION. As soon that will be ok I will submit again the driver for sti platform.
After reading your mail I have the feeling that solves cache, devicetree and legacy support problems will be difficult.
Since "Unix Device Memory Allocator" claims that it will solve memory requirements for us, would it not be more simple to write "standalone" drivers for each memory type (CMA, carveout, etc..) ? What I have in mind is a set of kernel allocators sharing a minimum of code like some ioctl and /dev/allocator/xxx
The drawback is that we have to start something for scratch but could it complementary to what you are doing?
Yes, that's the direction I was thinking about as well. I expect the Unix Device Allocator to take care of the constraint solving problem and the Ion/kernel portion to focus primarily on enumeration.
Thanks, Laura
Regards, Benjamin
2016-11-18 22:07 GMT+01:00 Laura Abbott labbott@redhat.com:
Hi,
At LPC, I proposed a moratorium on new Ion features because of issues preventing Ion ever moving out of staging. Among other problems, the Ion caching model hasn't made much progress to a solution that is widely accepted and there are still problems with devicetree support. There were no strong objections to this proposal so I propose continuing with a moratorium for at least the next 6 months to a year to actually work on a new architecture. If this hasn't made much progress by then I plan to hand off Ion to someone else to try other approaches.
There's been some discussion about a Unix Device Memory Allocator https://github.com/cubanismo/allocator . Ideally, this would be a complete replacement for Ion. This means capturing Ion or Ion-like requirements. The current proposal mostly focuses on userspace requirements and assumes Ion is just acting as an enumerator of various memory to allocate. This is a good direction. Ideally some of the Ion kernel code could be leveraged for a 'generic device memory allocator'. This device allocator should also be support use cases such as the SMAF (secure memory allocation framework) which has also been a work in progress.
One of the big open problems, as mentioned above, is the caching model. Specifying an uncached buffer at allocation time requires doing cache operations outside of the DMA framework which makes a bunch of maintainers unhappy. None of the arguments I've given for justification have really stuck which is a good sign that Ion should probably not be doing cache operations. If we ignore the Ion page pooling feature, this could be fixed by requiring that drivers call dma_buf_map and calling dma_map there. This gets tricker when drivers want to call mmap from userspace before passing the buffer down to ensure coherency. This model will need some more thought and possibly integration with Android.
I'd like to keep using linaro-mm-sig as a mailing list for Ion discussion as well as drivers-devel. If it would help to have another place for tracking/discussion I can see about setting that up as well.
Thanks, Laura
Linaro-mm-sig mailing list Linaro-mm-sig@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-mm-sig
linaro-mm-sig@lists.linaro.org
-
Benjamin Gaignard -
Dan Carpenter -
Laura Abbott