On Sunday 01 May 2011 20:11:59 Zach Pfeffer wrote:
- User space API
1.1. New memory management(MM) features should includes followings to the user space.: UMP A. user space API for memory allocation from system memory: UMP Any user process can allocate memory from kernel space by new MM model.
I don't think it can be that simple, you need to at least enforce some limits about the amount of nonswappable memory to be allocated to each unpriviledged process, or you need to limit which processes are allowed to allocate these buffers.
The alternative would be that regular user memory (e.g. from tmpfs) can be used for this and is only pinned inside of a DRM ioctl while passed to the hardware and released when returning from that, but that would not allow any long-running mappings to be mapped into user space.
Hi, my name is Sanghyun Lee. Thanks for your comments.
As you wrote above, it can't be a simple work, but we need it. we need to map user allocated memory(malloc) to the device which has a SYSTEM MMU(= IOMMU). At this time, we think that new API at user space. So, we have allocated memory at system space and mapped it to the user space by new API. Because some project does not based on DRM/DRI and X window-system. But, IOMMU APIs will be helpful for this, I guess.
There are a couple of things to keep in mind about IOMMU mappings of malloc'd memory. The first is that the demand paging system that supports malloc doesn't guarantee anything about the number and type of mappings used to satisfy a request. This can cause performance problems. With page alignment the few entries available in the TLBs will be quickly used up. On a TLB miss the IOMMU will stall the devices behind it while it pulls the new mapping into the TLB. If these mappings are mapped with 1 MB mappings instead of 4 KB mappings (page sized) then these misses happen much less frequently. This fine grained control means you really need a device aware driver that knows how memory should be mapped for a given device. Everyones been writing these, but no ones agreed on a common interface.
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.
I can certainly see the allure of malloc'd memory to IOMMU mapping, but unless people are careful it can cause many problems and may limit performance. Plus it doesn't handle permission - the fd approach might handle that. Maybe we just collect all the drivers and all agree on a set of IOCTLs?