From mboxrd@z Thu Jan 1 00:00:00 1970 From: m.nazarewicz@samsung.com (=?utf-8?B?TWljaGHFgiBOYXphcmV3aWN6?=) Date: Fri, 20 Aug 2010 03:08:24 +0200 Subject: [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework In-Reply-To: <20100820001339N.fujita.tomonori@lab.ntt.co.jp> References: <20100820001339N.fujita.tomonori@lab.ntt.co.jp> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, 19 Aug 2010 17:15:12 +0200, FUJITA Tomonori wrote: > On Wed, 18 Aug 2010 12:01:35 +0900 > Kyungmin Park wrote: > >> Are there any comments or ack? >> >> We hope this method included at mainline kernel if possible. >> It's really needed feature for our multimedia frameworks. > > You got any comments from mm people? > > Virtually, this adds a new memory allocator implementation that steals > some memory from memory allocator during boot process. Its API looks > completely different from the API for memory allocator. That doesn't > sound appealing to me much. This stuff couldn't be integrated well > into memory allocator? What kind of integration do you mean? I see three levels: 1. Integration on API level meaning that some kind of existing API is used instead of new cma_*() calls. CMA adds notion of devices and memory types which is new to all the other APIs (coherent has notion of devices but that's not enough). This basically means that no existing API can be used for CMA. On the other hand, removing notion of devices and memory types would defeat the whole purpose of CMA thus destroying the solution that CMA provides. 2. Reuse of memory pools meaning that memory reserved by CMA can then be used by other allocation mechanisms. This is of course possible. For instance coherent could easily be implemented as a wrapper to CMA. This is doable and can be done in the future after CMA gets more recognition. 3. Reuse of algorithms meaning that allocation algorithms used by other allocators will be used with CMA regions. This is doable as well and can be done in the future. -- 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-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751338Ab0HTBJR (ORCPT ); Thu, 19 Aug 2010 21:09:17 -0400 Received: from mailout4.w1.samsung.com ([210.118.77.14]:14554 "EHLO mailout4.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750883Ab0HTBJP convert rfc822-to-8bit (ORCPT ); Thu, 19 Aug 2010 21:09:15 -0400 MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed; delsp=yes Date: Fri, 20 Aug 2010 03:08:24 +0200 From: =?utf-8?B?TWljaGHFgiBOYXphcmV3aWN6?= Subject: Re: [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework In-reply-to: <20100820001339N.fujita.tomonori@lab.ntt.co.jp> To: kyungmin.park@samsung.com, FUJITA Tomonori Cc: linux-mm@kvack.org, dwalker@codeaurora.org, linux@arm.linux.org.uk, corbet@lwn.net, p.osciak@samsung.com, broonie@opensource.wolfsonmicro.com, linux-kernel@vger.kernel.org, hvaibhav@ti.com, hverkuil@xs4all.nl, kgene.kim@samsung.com, zpfeffer@codeaurora.org, jaeryul.oh@samsung.com, linux-media@vger.kernel.org, linux-arm-kernel@lists.infradead.org, m.szyprowski@samsung.com Message-id: Organization: Samsung Electronics Content-transfer-encoding: 8BIT User-Agent: Opera Mail/10.61 (Linux) References: <20100820001339N.fujita.tomonori@lab.ntt.co.jp> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 19 Aug 2010 17:15:12 +0200, FUJITA Tomonori wrote: > On Wed, 18 Aug 2010 12:01:35 +0900 > Kyungmin Park wrote: > >> Are there any comments or ack? >> >> We hope this method included at mainline kernel if possible. >> It's really needed feature for our multimedia frameworks. > > You got any comments from mm people? > > Virtually, this adds a new memory allocator implementation that steals > some memory from memory allocator during boot process. Its API looks > completely different from the API for memory allocator. That doesn't > sound appealing to me much. This stuff couldn't be integrated well > into memory allocator? What kind of integration do you mean? I see three levels: 1. Integration on API level meaning that some kind of existing API is used instead of new cma_*() calls. CMA adds notion of devices and memory types which is new to all the other APIs (coherent has notion of devices but that's not enough). This basically means that no existing API can be used for CMA. On the other hand, removing notion of devices and memory types would defeat the whole purpose of CMA thus destroying the solution that CMA provides. 2. Reuse of memory pools meaning that memory reserved by CMA can then be used by other allocation mechanisms. This is of course possible. For instance coherent could easily be implemented as a wrapper to CMA. This is doable and can be done in the future after CMA gets more recognition. 3. Reuse of algorithms meaning that allocation algorithms used by other allocators will be used with CMA regions. This is doable as well and can be done in the future. -- 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-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail190.messagelabs.com (mail190.messagelabs.com [216.82.249.51]) by kanga.kvack.org (Postfix) with SMTP id 28C896B02A9 for ; Thu, 19 Aug 2010 21:09:18 -0400 (EDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed; delsp=yes Received: from eu_spt1 ([210.118.77.13]) by mailout3.w1.samsung.com (Sun Java(tm) System Messaging Server 6.3-8.04 (built Jul 29 2009; 32bit)) with ESMTP id <0L7F00GX4F7C9S70@mailout3.w1.samsung.com> for linux-mm@kvack.org; Fri, 20 Aug 2010 02:09:14 +0100 (BST) Received: from localhost ([10.89.8.241]) by spt1.w1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0L7F00MC3F62AL@spt1.w1.samsung.com> for linux-mm@kvack.org; Fri, 20 Aug 2010 02:09:12 +0100 (BST) Date: Fri, 20 Aug 2010 03:08:24 +0200 From: =?utf-8?B?TWljaGHFgiBOYXphcmV3aWN6?= Subject: Re: [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework In-reply-to: <20100820001339N.fujita.tomonori@lab.ntt.co.jp> Message-id: Content-transfer-encoding: Quoted-Printable References: <20100820001339N.fujita.tomonori@lab.ntt.co.jp> Sender: owner-linux-mm@kvack.org To: kyungmin.park@samsung.com, FUJITA Tomonori Cc: linux-mm@kvack.org, dwalker@codeaurora.org, linux@arm.linux.org.uk, corbet@lwn.net, p.osciak@samsung.com, broonie@opensource.wolfsonmicro.com, linux-kernel@vger.kernel.org, hvaibhav@ti.com, hverkuil@xs4all.nl, kgene.kim@samsung.com, zpfeffer@codeaurora.org, jaeryul.oh@samsung.com, linux-media@vger.kernel.org, linux-arm-kernel@lists.infradead.org, m.szyprowski@samsung.com List-ID: On Thu, 19 Aug 2010 17:15:12 +0200, FUJITA Tomonori wrote: > On Wed, 18 Aug 2010 12:01:35 +0900 > Kyungmin Park wrote: > >> Are there any comments or ack? >> >> We hope this method included at mainline kernel if possible. >> It's really needed feature for our multimedia frameworks. > > You got any comments from mm people? > > Virtually, this adds a new memory allocator implementation that steals= > some memory from memory allocator during boot process. Its API looks > completely different from the API for memory allocator. That doesn't > sound appealing to me much. This stuff couldn't be integrated well > into memory allocator? What kind of integration do you mean? I see three levels: 1. Integration on API level meaning that some kind of existing API is us= ed instead of new cma_*() calls. CMA adds notion of devices and memory= types which is new to all the other APIs (coherent has notion of dev= ices but that's not enough). This basically means that no existing API c= an be used for CMA. On the other hand, removing notion of devices and mem= ory types would defeat the whole purpose of CMA thus destroying the solu= tion that CMA provides. 2. Reuse of memory pools meaning that memory reserved by CMA can then be= used by other allocation mechanisms. This is of course possible. F= or instance coherent could easily be implemented as a wrapper to CMA. This is doable and can be done in the future after CMA gets more recognition. 3. Reuse of algorithms meaning that allocation algorithms used by other allocators will be used with CMA regions. This is doable as well an= d can be done in the future. -- = Best regards, _ _ | Humble Liege of Serenely Enlightened Majesty of o' \,=3D./ `o | Computer Science, Micha=C5=82 "mina86" Nazarewicz (o o) +----[mina86*mina86.com]---[mina86*jabber.org]----ooO--(_)--Ooo-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org