On 05/03/2011 09:35 AM, Arnd Bergmann wrote:
On Tuesday 03 May 2011, Laurent Pinchart wrote:
The other thing about malloc'd memory is that the kernel doesn't actually commit any physical memory to the request until someone writes to it (copy-on-write). On a write the kernel will fault in an anonymous page whether malloc use sbrk or mmap(). What this means is that an IOMMU map can't be set up until after the page has been mapped in.
The OMAP3 ISP (V4L2) driver supports that. It will call get_user_pages() on the buffer passed by userspace, so pages will be faulted in at that point.
A lot of drivers do that, e.g. all of infiniband is built around this. It's not black magic, but I would usually prefer allocating memory in kernel to pass it to user space to avoid a lot of the potential issues.
For instance, when memory is already mapped into user space, you should no longer change its page attributes (cached/write-combined/...) and you have to deal with arbitrarily strange user pointers passed into the kernel.
I would venture a guess that most of these graphics solutions that use user space based memory do so because there was no suitable kernel level API available at the time.
I've been trying to look at use cases and outside of the possibility of using shmem backed memory, I'm not really seeing anything that wouldn't be easier and safer with the memory allocated in the kernel.
It will have to be a longer term goal of this group that whatever solution we use comes with the necessary EGL extensions to facilitate creating and using the shared memory (e.g. EGL_MESA_drm_image) so that people will have less need to create their own one-off EGL image extensions to pass about questionable memory.
Jordan