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.
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?
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?
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.
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.
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?
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?
- 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.
- 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.
- 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