Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757004Ab0GUSKm (ORCPT ); Wed, 21 Jul 2010 14:10:42 -0400 Received: from mailout4.w1.samsung.com ([210.118.77.14]:63076 "EHLO mailout4.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751260Ab0GUSKj convert rfc822-to-8bit (ORCPT ); Wed, 21 Jul 2010 14:10:39 -0400 MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed; delsp=yes Date: Wed, 21 Jul 2010 20:11:53 +0200 From: =?utf-8?B?TWljaGHFgiBOYXphcmV3aWN6?= Subject: Re: [PATCH 2/4] mm: cma: Contiguous Memory Allocator added In-reply-to: <1279733750.31376.14.camel@c-dwalke-linux.qualcomm.com> To: Daniel Walker Cc: linux-mm@kvack.org, Marek Szyprowski , Pawel Osciak , Xiaolin Zhang , Hiremath Vaibhav , Robert Fekete , Marcus Lorentzon , linux-kernel@vger.kernel.org, Kyungmin Park , linux-arm-msm@vger.kernel.org Message-id: Organization: Samsung Electronics Content-transfer-encoding: 8BIT User-Agent: Opera Mail/10.60 (Linux) References: <1279649724.26765.23.camel@c-dwalke-linux.qualcomm.com> <1279654698.26765.31.camel@c-dwalke-linux.qualcomm.com> <1279733750.31376.14.camel@c-dwalke-linux.qualcomm.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4219 Lines: 114 On Wed, 21 Jul 2010 19:35:50 +0200, Daniel Walker wrote: > On Wed, 2010-07-21 at 14:01 +0200, Michał Nazarewicz wrote: > >> What you are asking for is: >> >> cma=a=100M cma_map=*/*=a >> >> All devices will share the same region so that "if the video driver isn't >> using the memory" then "something else can use it". (please excuse me quoting >> you, it was stronger then me ;) ). > > Ok .. > >> Driver has to little information to say whether it really stopped using >> memory. Maybe the next call will be to allocate buffers for frames and >> initialise the chip? Sure, some “good enough” defaults can be provided >> (and the framework allows that) but still platform architect might need >> more power. > > I think your talking more about optimization .. You can take that into > account .. Well, yes, that's one of the points: to minimise amount of memory reserved for devices. >> > (btw, these strings your creating yikes, talk about confusing ..) >> >> They are not that scary really. Let's look at cma: >> >> a=10M;b=10M >> >> Split it on semicolon: >> >> a=10M >> b=10M >> >> and you see that it defines two regions (a and b) 10M each. > > I think your assuming a lot .. I've never seen the notation before I > wouldn't assuming there's regions or whatever .. That's why there is documentation with grammar included. :) >> As of cma_map: >> >> camera,video=a;jpeg,scaler=b >> >> Again split it on semicolon: >> >> camera,video=a >> jpeg,scaler=b >> >> Now, substitute equal sign by "use(s) region(s)": >> >> camera,video use(s) region(s): a >> jpeg,scaler use(s) region(s): b >> >> No black magic here. ;) > > It way too complicated .. Users (i.e. not programmers) has to use > this .. Not really. This will probably be used mostly on embedded systems where users don't have much to say as far as hardware included on the platform is concerned, etc. Once a phone, tablet, etc. is released users will have little need for customising those strings. On desktop computers on the other hand, the whole framework may be completely useless as devices are more likely to have IO map or scatter/getter capabilities. Plus, as I mentioned above, some “good enough” defaults can be provided. >> >> One of the purposes of the CMA framework is to make it let device >> >> drivers completely forget about the memory management and enjoy >> >> a simple API. >> > >> > The driver, and it's maintainer, are really the best people to know how >> > much memory they need and when it's used/unused. You don't really want >> > to architect them out. >> >> This might be true if there is only one device but even then it's not >> always the case. If many devices need physically-contiguous memory >> there is no way for them to communicate and share memory. For best >> performance someone must look at them and say who gets what. > > How do you think regular memory allocation work? I mean there's many > devices that all need different amounts of memory and they get along. > Yet your saying it's not possible . Regular memory allocation either does not allow you to allocate big chunks of memory (kmalloc) or uses MMU (vmalloc). The purpose of CMA is to provide a framework for allocators of big physically-contiguous chunks of memory. If a driver needs several KiB it just uses kmalloc() which handles such allocations just fine. However, we are taking about 6MiB full-HD frame or a photo from 5 megapixel camera. Currently, drivers are developed which create their own mechanism for allocating such chunks of memory. Often based on bootmem. CMA will unify all those mechanism and let it easier to manage them plus will allow for many drivers to share regions. -- Best regards, _ _ | Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o | Computer Science, Michał "mina86" Nazarewicz (o o) +----[mina86*mina86.com]---[mina86*jabber.org]----ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/