-----Original Message----- From: Arnd Bergmann [mailto:arnd@arndb.de] Sent: Wednesday, April 27, 2011 12:43 AM To: linaro-mm-sig@lists.linaro.org; sanghyun75.lee@samsung.com; Marek Szyprowski Subject: Re: [Linaro-mm-sig] Requirements for Memory Management
On Monday 25 April 2011, 이상현 wrote:
Hi all,
The followings are Samsung S.LSI's requirement for unified memory
manager.
- 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.
B. user space API for cache operations: flush, clean, invalidate Any user process can do cache operation on the allocated memory.
IMHO these should be on a much higher level. For an architecture independent API, you can not assume that cache management operations are available or necessary. I suggest building these on top of the dma mapping operations we have: dma_sync_to_device and dma_sync_to_cpu.
On fully coherent architectures, or when you have uncached mappings, these will simply be ignored, while for noncoherent cached mappings, they would turn into flush or invalidate cache operations.
Do you see any scenarios that cannot be built on top of these interfaces?
Most of the use case, there is no scenario call cache APIs at user space, except 3D. Actually, I don't know why the 3D requires this API to memory management at user side. As for this, I'll check about the use case.
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.
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.
2-1. Physically memory allocator A. kernel space API for contiguous memory allocation: CMA(*) B. kernel space API for non-contiguous memory allocation: VCMM (*) C. start address alignment: CMA, VCMM D. selectable allocating region: CMA *refer to the bottom's extension.
You are confusing requirements with the implementation. You cannot require something that has been rejected as a patch. Let us discuss first what the requirement is, then how we can implement that.
These implementations are our reference for memory allocation.
2-2. Device virtual address management: VCMM New MM features should provide the way of managing device virtual memory address as like followings:
A. IOMMU(System MMU) support IOMMU is a kind of memory MMU, but IOMMU is dedicated for each device.
we have the iommu API for this. do you need anything beyond that?
B. device virtual address mapping for each device
this seems to refer to the dma-mapping api
C. virtual memory allocation
vmalloc?
D. mapping / remapping between phys and device virtual address
What is the difference to B?
E. dedicated device virtual address space for each device
This is a hardware feature that some systems have, but others have not. I guess what you mean is that we need to be able to deal with both kinds of hardware, right?
All your comments on IOMMU are clear and will be useful for us. Though IOMMU is a hardware features that only some system have, this features needs to be considered at Linaro@UDS.
--- You can find the implementation in the following git repository. http://git.kernel.org/?p=linux/kernel/git/kki_ap/linux-2.6- samsung.git;a=tree;hb=refs/heads/2.6.36-samsung
- UMP (Unified Memory Provider)
- The UMP is an auxiliary component which enables memory to be shared across different applications, drivers and hardware components.
http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver- open-source/page__cid__133__show__newcomment/
- Suggested by ARM, Not submitted yet.
- implementation drivers/media/video/samsung/ump/*
Last time I looked at UMP, it was in a rather bad shape, and I would not consider this worth using or building on top of. Has there been progress on this front?
IMHO it needs some modifications. We just used UMP with as-is conditions.
- VCMM (Virtual Contiguous Memory Manager)
- The VCMM is a framework to deal with multiple IOMMUs in a system with intuitive and abstract objects
- Submitted by Michal Nazarewicz @Samsung-SPRC
- Also submitted by KyongHo Cho @Samsung-SYS.LSI
- http://article.gmane.org/gmane.linux.kernel.mm/56912/match=vcm
- implementation include/linux/vcm.h include/linux/vcm-drv.h mm/vcm.c arch/arm/plat-s5p/s5p-vcm.c arch/amr/plat-s5p/include/plat/s5p-vcm.h
This really needs to be integrated into the existing APIs. The code looks clean and well documented, but it duplicates functionality that is already available elsewhere, which is something that Marek is already working on.
I heard that Zach will present this issues on UDS.
- CMA (Contiguous Memory Allocator)
- The Contiguous Memory Allocator (CMA) is a framework, which allows setting up a machine-specific configuration for physically-contiguous memory management. Memory for devices is then allocated according to that configuration.
- http://lwn.net/Articles/396702/
- http://www.spinics.net/lists/linux-media/msg26486.html
- Submitted by Michal Nazarewicz @Samsung-SPRC
- implementation mm/cma.c include/linux/cma.h
This should probably be hidden behind the dma-mapping API as well, instead of having a interface visible to the device drivers.
As to this, Marek (from Samsung's Poland) will present CMA at UDS.
- SYS.MMU
- System MMU supports address transition from VA to PA.
- http://thread.gmane.org/gmane.linux.kernel.samsung-soc/3909
- Submitted by Sangbeom Kim
- Merged by Kukjin Kim, ARM/S5P ARM ARCHITECTURES maintainer
- implementation arch/arm/plat-s5p/sysmmu.c arch/arm/plat-s5p/include/plat/sysmmu.h
About to go away once replaced with standard iommu code, hopefully.
Arnd