[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linaro-mm-sig
Subject:    [Linaro-mm-sig] Requirements for Memory Management
From:       arnd () arndb ! de (Arnd Bergmann)
Date:       2011-04-26 15:42:55
Message-ID: 201104261742.55681.arnd () arndb ! de
[Download RAW message or body]

On Monday 25 April 2011, ??? wrote:
> Hi all,
> 
> The followings are Samsung S.LSI's requirement for unified memory manager.
> 
> 1. 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.
> 
> 2. 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
> 
> 1. 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?

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

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

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


[prev in list] [next in list] [prev in thread] [next in thread]