From mboxrd@z Thu Jan 1 00:00:00 1970 From: m.nazarewicz@samsung.com (=?utf-8?B?TWljaGHFgiBOYXphcmV3aWN6?=) Date: Thu, 26 Aug 2010 06:01:56 +0200 Subject: [PATCH/RFCv4 0/6] The Contiguous Memory Allocator framework In-Reply-To: <20100826124434.6089630d.kamezawa.hiroyu@jp.fujitsu.com> References: <1282310110.2605.976.camel@laptop> <20100825155814.25c783c7.akpm@linux-foundation.org> <20100826095857.5b821d7f.kamezawa.hiroyu@jp.fujitsu.com> <20100826115017.04f6f707.kamezawa.hiroyu@jp.fujitsu.com> <20100826124434.6089630d.kamezawa.hiroyu@jp.fujitsu.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org KAMEZAWA Hiroyuki wrote: > 128MB...too big ? But it's depend on config. On embedded systems it may be like half of the RAM. Or a quarter. So bigger granularity could be desired on some platforms. > IBM's ppc guys used 16MB section, and recently, a new interface to shrink > the number of /sys files are added, maybe usable. > > Something good with this approach will be you can create "cma" memory > before installing driver. That's how CMA works at the moment. But if I understand you correctly, what you are proposing would allow to reserve memory *at* *runtime* long after system has booted. This would be a nice feature as well though. > But yes, complicated and need some works. > Ah, I need to clarify what I want to say. > > With compaction, it's helpful, but you can't get contiguous memory larger > than MAX_ORDER, I think. To get memory larger than MAX_ORDER on demand, > memory hot-plug code has almost all necessary things. I'll try to look at it then. > BTW, just curious...the memory for cma need not to be saved at > hibernation ? Or drivers has to write its own hibernation ops by driver suspend > udev or some ? Hibernation was not considered as of yet but I think it's device driver's responsibility more then CMA's especially since it may make little sense to save some of the buffers -- ie. no need to keep a frame from camera since it'll be overwritten just after system wakes up from hibernation. It may also be better to stop playback and resume it later on rather than trying to save decoder's state. Again though, I haven't thought about hibernation as of yet. -- 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 S1751529Ab0HZEDE (ORCPT ); Thu, 26 Aug 2010 00:03:04 -0400 Received: from mailout1.w1.samsung.com ([210.118.77.11]:56822 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750707Ab0HZEDC convert rfc822-to-8bit (ORCPT ); Thu, 26 Aug 2010 00:03:02 -0400 Date: Thu, 26 Aug 2010 06:01:56 +0200 From: =?utf-8?B?TWljaGHFgiBOYXphcmV3aWN6?= Subject: Re: [PATCH/RFCv4 0/6] The Contiguous Memory Allocator framework In-reply-to: <20100826124434.6089630d.kamezawa.hiroyu@jp.fujitsu.com> To: KAMEZAWA Hiroyuki Cc: FUJITA Tomonori , Daniel Walker , Russell King , Jonathan Corbet , Peter Zijlstra , Pawel Osciak , Konrad Rzeszutek Wilk , linux-kernel@vger.kernel.org, Mel Gorman , Hans Verkuil , linux-mm@kvack.org, Kyungmin Park , Zach Pfeffer , Mark Brown , Andrew Morton , Marek Szyprowski , linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org Message-id: Organization: Samsung Electronics MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-transfer-encoding: 8BIT User-Agent: Opera Mail/10.61 (Linux) References: <1282310110.2605.976.camel@laptop> <20100825155814.25c783c7.akpm@linux-foundation.org> <20100826095857.5b821d7f.kamezawa.hiroyu@jp.fujitsu.com> <20100826115017.04f6f707.kamezawa.hiroyu@jp.fujitsu.com> <20100826124434.6089630d.kamezawa.hiroyu@jp.fujitsu.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org KAMEZAWA Hiroyuki wrote: > 128MB...too big ? But it's depend on config. On embedded systems it may be like half of the RAM. Or a quarter. So bigger granularity could be desired on some platforms. > IBM's ppc guys used 16MB section, and recently, a new interface to shrink > the number of /sys files are added, maybe usable. > > Something good with this approach will be you can create "cma" memory > before installing driver. That's how CMA works at the moment. But if I understand you correctly, what you are proposing would allow to reserve memory *at* *runtime* long after system has booted. This would be a nice feature as well though. > But yes, complicated and need some works. > Ah, I need to clarify what I want to say. > > With compaction, it's helpful, but you can't get contiguous memory larger > than MAX_ORDER, I think. To get memory larger than MAX_ORDER on demand, > memory hot-plug code has almost all necessary things. I'll try to look at it then. > BTW, just curious...the memory for cma need not to be saved at > hibernation ? Or drivers has to write its own hibernation ops by driver suspend > udev or some ? Hibernation was not considered as of yet but I think it's device driver's responsibility more then CMA's especially since it may make little sense to save some of the buffers -- ie. no need to keep a frame from camera since it'll be overwritten just after system wakes up from hibernation. It may also be better to stop playback and resume it later on rather than trying to save decoder's state. Again though, I haven't thought about hibernation as of yet. -- 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 mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227]) by kanga.kvack.org (Postfix) with SMTP id 2EA816B01F0 for ; Thu, 26 Aug 2010 00:03:03 -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 <0L7Q00C1YR8ZF9@mailout2.w1.samsung.com> for linux-mm@kvack.org; Thu, 26 Aug 2010 05:02:59 +0100 (BST) Received: from linux.samsung.com ([106.116.38.10]) by spt1.w1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0L7Q00KXNR8Z1V@spt1.w1.samsung.com> for linux-mm@kvack.org; Thu, 26 Aug 2010 05:02:59 +0100 (BST) Date: Thu, 26 Aug 2010 06:01:56 +0200 From: =?utf-8?B?TWljaGHFgiBOYXphcmV3aWN6?= Subject: Re: [PATCH/RFCv4 0/6] The Contiguous Memory Allocator framework In-reply-to: <20100826124434.6089630d.kamezawa.hiroyu@jp.fujitsu.com> Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-transfer-encoding: Quoted-Printable References: <1282310110.2605.976.camel@laptop> <20100825155814.25c783c7.akpm@linux-foundation.org> <20100826095857.5b821d7f.kamezawa.hiroyu@jp.fujitsu.com> <20100826115017.04f6f707.kamezawa.hiroyu@jp.fujitsu.com> <20100826124434.6089630d.kamezawa.hiroyu@jp.fujitsu.com> Sender: owner-linux-mm@kvack.org To: KAMEZAWA Hiroyuki Cc: FUJITA Tomonori , Daniel Walker , Russell King , Jonathan Corbet , Peter Zijlstra , Pawel Osciak , Konrad Rzeszutek Wilk , linux-kernel@vger.kernel.org, Mel Gorman , Hans Verkuil , linux-mm@kvack.org, Kyungmin Park , Zach Pfeffer , Mark Brown , Andrew Morton , Marek Szyprowski , linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org List-ID: KAMEZAWA Hiroyuki wrote: > 128MB...too big ? But it's depend on config. On embedded systems it may be like half of the RAM. Or a quarter. So b= igger granularity could be desired on some platforms. > IBM's ppc guys used 16MB section, and recently, a new interface to shr= ink > the number of /sys files are added, maybe usable. > > Something good with this approach will be you can create "cma" memory > before installing driver. That's how CMA works at the moment. But if I understand you correctly, = what you are proposing would allow to reserve memory *at* *runtime* long afte= r system has booted. This would be a nice feature as well though. > But yes, complicated and need some works. > Ah, I need to clarify what I want to say. > > With compaction, it's helpful, but you can't get contiguous memory lar= ger > than MAX_ORDER, I think. To get memory larger than MAX_ORDER on demand= , > memory hot-plug code has almost all necessary things. I'll try to look at it then. > BTW, just curious...the memory for cma need not to be saved at > hibernation ? Or drivers has to write its own hibernation ops by drive= r suspend > udev or some ? Hibernation was not considered as of yet but I think it's device driver'= s responsibility more then CMA's especially since it may make little sense= to save some of the buffers -- ie. no need to keep a frame from camera since it'= ll be overwritten just after system wakes up from hibernation. It may also be= better to stop playback and resume it later on rather than trying to save decod= er's state. Again though, I haven't thought about hibernation as of yet. -- = 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