From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752783Ab0HTKyu (ORCPT ); Fri, 20 Aug 2010 06:54:50 -0400 Received: from mailout3.w1.samsung.com ([210.118.77.13]:45924 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751184Ab0HTKys convert rfc822-to-8bit (ORCPT ); Fri, 20 Aug 2010 06:54:48 -0400 MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed; delsp=yes Date: Fri, 20 Aug 2010 12:54:02 +0200 From: =?utf-8?B?TWljaGHFgiBOYXphcmV3aWN6?= Subject: Re: [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework In-reply-to: <20100820193328P.fujita.tomonori@lab.ntt.co.jp> To: FUJITA Tomonori Cc: hverkuil@xs4all.nl, 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, linux-mm@kvack.org, kyungmin.park@samsung.com, kgene.kim@samsung.com, zpfeffer@codeaurora.org, jaeryul.oh@samsung.com, m.szyprowski@samsung.com, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org Message-id: Organization: Samsung Electronics Content-transfer-encoding: 8BIT User-Agent: Opera Mail/10.61 (Linux) References: <20100820155617S.fujita.tomonori@lab.ntt.co.jp> <20100820193328P.fujita.tomonori@lab.ntt.co.jp> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 20 Aug 2010 12:35:01 +0200, FUJITA Tomonori wrote: > On Fri, 20 Aug 2010 10:10:45 +0200 > **UNKNOWN CHARSET** wrote: > >> > I wrote "similar to the existing API', not "reuse the existing API". >> >> Yes, but I don't really know what you have in mind. CMA is similar to various >> APIs in various ways: it's similar to any allocator since it takes >> size in bytes, > > why don't take gfp_t flags? Because they are insufficient. Either that or I don't understand gfp_t. With CMA, platform can define many memory types. For instance, if there are two memory bans there can be two memory types for the two banks. For at least one of the device I'm in contact with, another type for it's firmware is also needed. Bottom line is that there may be possibly many types which won't map to gfp_t. > Something like dev_alloc_page is more appropriate name? Two things: I'd prefer a "cma" prefix rather then "dev" and I think it should be "pages", right? Then, size should be given in pages rather then bytes. Nonetheless, I don't really see at the moment why this should be better. > Or something similar to dmapool API (mm/dmapool.c) might work > better. The purpose of dmapool API is creating a pool for consistent > memory per device. It's similar to yours, creating a pool for > contiguous memory per device(s)? I'll try to look at it later on and think about it. I'm still somehow reluctant to change the names but still, thank you for suggestions. -- 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 mail137.messagelabs.com (mail137.messagelabs.com [216.82.249.19]) by kanga.kvack.org (Postfix) with SMTP id AB5D96B0324 for ; Fri, 20 Aug 2010 06:54:47 -0400 (EDT) Received: from eu_spt1 (mailout2.w1.samsung.com [210.118.77.12]) by mailout2.w1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0L7G00C2O6BAW1@mailout2.w1.samsung.com> for linux-mm@kvack.org; Fri, 20 Aug 2010 11:54:46 +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 <0L7G000CR6A43V@spt1.w1.samsung.com> for linux-mm@kvack.org; Fri, 20 Aug 2010 11:54:45 +0100 (BST) Date: Fri, 20 Aug 2010 12:54:02 +0200 From: =?utf-8?B?TWljaGHFgiBOYXphcmV3aWN6?= Subject: Re: [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework In-reply-to: <20100820193328P.fujita.tomonori@lab.ntt.co.jp> Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-transfer-encoding: Quoted-Printable References: <20100820155617S.fujita.tomonori@lab.ntt.co.jp> <20100820193328P.fujita.tomonori@lab.ntt.co.jp> Sender: owner-linux-mm@kvack.org To: FUJITA Tomonori Cc: hverkuil@xs4all.nl, 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, linux-mm@kvack.org, kyungmin.park@samsung.com, kgene.kim@samsung.com, zpfeffer@codeaurora.org, jaeryul.oh@samsung.com, m.szyprowski@samsung.com, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org List-ID: On Fri, 20 Aug 2010 12:35:01 +0200, FUJITA Tomonori wrote: > On Fri, 20 Aug 2010 10:10:45 +0200 > **UNKNOWN CHARSET** wrote: > >> > I wrote "similar to the existing API', not "reuse the existing API"= . >> >> Yes, but I don't really know what you have in mind. CMA is similar t= o various >> APIs in various ways: it's similar to any allocator since it takes >> size in bytes, > > why don't take gfp_t flags? Because they are insufficient. Either that or I don't understand gfp_t.= With CMA, platform can define many memory types. For instance, if there= are two memory bans there can be two memory types for the two banks. For at= least one of the device I'm in contact with, another type for it's firmware is als= o needed. Bottom line is that there may be possibly many types which won't map to = gfp_t. > Something like dev_alloc_page is more appropriate name? Two things: I'd prefer a "cma" prefix rather then "dev" and I think it s= hould be "pages", right? Then, size should be given in pages rather then bytes= . Nonetheless, I don't really see at the moment why this should be better.= > Or something similar to dmapool API (mm/dmapool.c) might work > better. The purpose of dmapool API is creating a pool for consistent > memory per device. It's similar to yours, creating a pool for > contiguous memory per device(s)? I'll try to look at it later on and think about it. I'm still somehow r= eluctant to change the names but still, thank you for suggestions. -- = 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: m.nazarewicz@samsung.com (=?utf-8?B?TWljaGHFgiBOYXphcmV3aWN6?=) Date: Fri, 20 Aug 2010 12:54:02 +0200 Subject: [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework In-Reply-To: <20100820193328P.fujita.tomonori@lab.ntt.co.jp> References: <20100820155617S.fujita.tomonori@lab.ntt.co.jp> <20100820193328P.fujita.tomonori@lab.ntt.co.jp> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, 20 Aug 2010 12:35:01 +0200, FUJITA Tomonori wrote: > On Fri, 20 Aug 2010 10:10:45 +0200 > **UNKNOWN CHARSET** wrote: > >> > I wrote "similar to the existing API', not "reuse the existing API". >> >> Yes, but I don't really know what you have in mind. CMA is similar to various >> APIs in various ways: it's similar to any allocator since it takes >> size in bytes, > > why don't take gfp_t flags? Because they are insufficient. Either that or I don't understand gfp_t. With CMA, platform can define many memory types. For instance, if there are two memory bans there can be two memory types for the two banks. For at least one of the device I'm in contact with, another type for it's firmware is also needed. Bottom line is that there may be possibly many types which won't map to gfp_t. > Something like dev_alloc_page is more appropriate name? Two things: I'd prefer a "cma" prefix rather then "dev" and I think it should be "pages", right? Then, size should be given in pages rather then bytes. Nonetheless, I don't really see at the moment why this should be better. > Or something similar to dmapool API (mm/dmapool.c) might work > better. The purpose of dmapool API is creating a pool for consistent > memory per device. It's similar to yours, creating a pool for > contiguous memory per device(s)? I'll try to look at it later on and think about it. I'm still somehow reluctant to change the names but still, thank you for suggestions. -- 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--