Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752522Ab0HZBto (ORCPT ); Wed, 25 Aug 2010 21:49:44 -0400 Received: from mailout1.w1.samsung.com ([210.118.77.11]:53058 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752293Ab0HZBtl convert rfc822-to-8bit (ORCPT ); Wed, 25 Aug 2010 21:49:41 -0400 Date: Thu, 26 Aug 2010 03:49:00 +0200 From: =?utf-8?B?TWljaGHFgiBOYXphcmV3aWN6?= Subject: Re: [PATCH/RFCv4 0/6] The Contiguous Memory Allocator framework In-reply-to: <20100825173125.0855a6b0@bike.lwn.net> To: Andrew Morton , Jonathan Corbet Cc: Peter Zijlstra , linux-mm@kvack.org, Daniel Walker , FUJITA Tomonori , Hans Verkuil , Konrad Rzeszutek Wilk , Kyungmin Park , Marek Szyprowski , Mark Brown , Pawel Osciak , Russell King , Zach Pfeffer , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, Mel Gorman 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> <20100825173125.0855a6b0@bike.lwn.net> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2276 Lines: 42 On Thu, 26 Aug 2010 01:31:25 +0200, Jonathan Corbet wrote: > The original OLPC has a camera controller which requires three contiguous, > image-sized buffers in memory. That system is a little memory constrained > (OK, it's desperately short of memory), so, in the past, the chances of > being able to allocate those buffers anytime some kid decides to start > taking pictures was poor. Thus, cafe_ccic.c has an option to snag the > memory at initialization time and never let go even if you threaten its > family. Hell hath no fury like a little kid whose new toy^W educational > tool stops taking pictures. > > That, of course, is not a hugely efficient use of memory on a > memory-constrained system. If the VM could reliably satisfy those > allocation requestss, life would be wonderful. Seems difficult. But it > would be a nicer solution than CMA, which, to a great extent, is really > just a standardized mechanism for grabbing memory and never letting go. At this moment it seems nothing more then that but they way I see it is that with a common, standardised, centrally-managed mechanism for grabbing memory we can start thinking about the ways to reuse the memory. If each driver were to grab it's own memory in a way know to itself only the memory is truly lost but with CMA not only regions can be reused among devices but also the framework can manage the unallocated memory and try to utilize it in other ways (movable pages? cache? buffers? some kind of compressed memory swap?). What I'm trying to say is that I totally agree with your and other's comments about CMA essentially grabbing memory and never releasing it but I believe this can be combat with time when overall idea of haw the CMA API should look like is agreed upon. -- 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/