On Sunday 01 May 2011, 이상현 wrote:
From: Arnd Bergmann [mailto:arnd@arndb.de] On Monday 25 April 2011, 이상현 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.
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.
The iommu API solves some of the low-level problems in the kernel, which we need to solve but the user space interface is another problem.
For the user space interface, my feeling is that DRM should be the first choice, and we'd need a really good reason to come up with something different. As you said, some projects today use DRM, while others don't. It's probably far less work to convert only the ones that don't use DRM to use it, rather than changing all applications that interact with the graphics subsystem to use something completely new.
C. user space API for mapping memory attribute as cacheable When the system memory mapped into the user space, user process can set its property as cacheable. D. user space API for mapping memory attribute as non-cacheable When the system memory mapped into the user space, user process can set its property as non-cacheable.
Again, I would define these on a higher level. In the kernel, we use dma_alloc_coherent and dma_alloc_noncoherent, where the first one implies that you don't need to issue the dma_sync_* commands while the second one requires you to use them.
1.2. Inter-process memory sharing: UMP New MM features should provide memory sharing between user process.
A. Memory allocated by user space can be shared between user processes.
How is this different from regular posix shared memory?
It means user allocated memory should be mapped to another user processes.
Oh. Why would you do that? I recommend being extremely careful with what kind of memory you allow to be shared. There are a lot of possibilities for deadlocks and other problems with certain kinds of memory. Things that I can see going really bad include:
* an mmapped file on a remote file system like NFS * hardware memory mapped into one process using strange attributes (huge pages, noncacheable, ...) * memory that a process has mapped from another process using the same interface. * raw sockets
Rather than having a blacklist that forbids the really awkward cases, I would make a very short whitelist of stuff that can back memory that you allow to be shared, e.g. only tmpfs mappings.
B. Memory allocated by kernel space can be shared between user processes.
- Kernel space API
New MM features should includes followings to the kernel space.: CMA, VCMM
What does that mean? These are just TLAs, not specific features.
We need two memory allocators, one is for physically contiguous memory. Another one is for physically discontiguous memory.
No. We already have allocators for these, they are called alloc_pages() and vmalloc() ;-)
Doing new infrastructure of course is extremely hard and introducing a completely new in-kernel interface for anything is usually a bad idea. Most importantly, when you design something new, it should fit into the related APIs that are already there, to make it easier for people to use the new infrastructure.
When there are deficiencies with the interfaces that are already there, we should put all the effort into fixing these interfaces, rather than doing something new. It's clear from the discussions that we had so far that the dma-mapping interface is not enough, but I think that is totally fixable, and I definitely encourage anyone to point out flaws and come up with patches to make that better.
In case of VCMM, have a look at how the powerpc implementation integrates virtually contiguous allocations into the dma-mapping API, at arch/powerpc/kernel/iommu.c.
For CMA, I've looked at the patches again, and they clearly do far too much at once. I agree that we need something better to back contiguous allocations, especially when we want them to be outside of the kernel linear mapping. See the discussion on "Memory region attribute bits and multiple mappings" for this. Once we have an agreement on where the memory should come from (reserved at boot time as in CMA, unmapped from the linear mapping, or from highmem), we can start thinking about to to assign the memory to devices, with an API that works both for the IOMMU and linear cases.
The question of how to export buffers to user space is completely unrelated to this, and should not at all be part of the allocation code. This belongs into the subsystems that deal with the memory (videobuf2 and DRM), and it's hard enough to get those to work together.
Arnd