linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: m.nazarewicz@samsung.com (Michał Nazarewicz)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH/RFCv4 0/6] The Contiguous Memory Allocator framework
Date: Thu, 26 Aug 2010 03:49:00 +0200	[thread overview]
Message-ID: <op.vh0vbys97p4s8u@localhost> (raw)
In-Reply-To: <20100825173125.0855a6b0@bike.lwn.net>

On Thu, 26 Aug 2010 01:31:25 +0200, Jonathan Corbet <corbet@lwn.net> 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--

  parent reply	other threads:[~2010-08-26  1:49 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-20  9:50 [PATCH/RFCv4 0/6] The Contiguous Memory Allocator framework Michal Nazarewicz
2010-08-20  9:50 ` [PATCH/RFCv4 1/6] lib: rbtree: rb_root_init() function added Michal Nazarewicz
2010-08-20  9:50   ` [PATCH/RFCv4 2/6] mm: cma: Contiguous Memory Allocator added Michal Nazarewicz
2010-08-20  9:50     ` [PATCH/RFCv4 3/6] mm: cma: Added SysFS support Michal Nazarewicz
2010-08-20  9:50       ` [PATCH/RFCv4 4/6] mm: cma: Added command line parameters support Michal Nazarewicz
2010-08-20  9:50         ` [PATCH/RFCv4 5/6] mm: cma: Test device and application added Michal Nazarewicz
2010-08-20  9:50           ` [PATCH/RFCv4 6/6] arm: Added CMA to Aquila and Goni Michal Nazarewicz
2010-08-25 20:37       ` [PATCH/RFCv4 3/6] mm: cma: Added SysFS support Konrad Rzeszutek Wilk
2010-08-26  1:20         ` Michał Nazarewicz
2010-08-25 20:32     ` [PATCH/RFCv4 2/6] mm: cma: Contiguous Memory Allocator added Konrad Rzeszutek Wilk
2010-08-26  1:22       ` Michał Nazarewicz
2010-08-26  6:25     ` [PATCH/RFCv4.1 " Michal Nazarewicz
2010-08-26 13:47     ` [PATCH/RFCv4 " Mel Gorman
2010-08-27  2:09       ` Michał Nazarewicz
2010-08-28 12:37     ` Hans Verkuil
2010-08-29  1:48       ` Michał Nazarewicz
2010-08-20 13:15 ` [PATCH/RFCv4 0/6] The Contiguous Memory Allocator framework Peter Zijlstra
2010-08-25 22:58   ` Andrew Morton
2010-08-25 23:26     ` Daniel Walker
2010-08-26  1:38       ` Michał Nazarewicz
2010-08-25 23:31     ` Jonathan Corbet
2010-08-26  1:38       ` Pawel Osciak
2010-08-26  1:49       ` Michał Nazarewicz [this message]
2010-08-26  2:49       ` Minchan Kim
2010-08-26  3:04         ` Minchan Kim
2010-08-26  8:20         ` Peter Zijlstra
2010-08-26  9:29           ` Minchan Kim
2010-08-26 10:06             ` Peter Zijlstra
2010-08-26 10:21               ` Minchan Kim
2010-08-26 11:05                 ` Peter Zijlstra
2010-08-26  0:58     ` KAMEZAWA Hiroyuki
2010-08-26  2:12       ` Michał Nazarewicz
2010-08-26  2:50         ` KAMEZAWA Hiroyuki
2010-08-26  3:44           ` KAMEZAWA Hiroyuki
2010-08-26  4:01             ` Michał Nazarewicz
2010-08-26  4:39               ` KAMEZAWA Hiroyuki
2010-08-26  5:54               ` Américo Wang
2010-08-26  4:06             ` Minchan Kim
2010-08-26  4:14               ` Minchan Kim
2010-08-26  4:30               ` KAMEZAWA Hiroyuki
2010-08-26  9:36                 ` Minchan Kim
2010-08-27  8:16                   ` KAMEZAWA Hiroyuki
2010-08-27  8:37                     ` Peter Zijlstra
2010-09-02  8:54                     ` KAMEZAWA Hiroyuki
2010-09-03 10:29                       ` KAMEZAWA Hiroyuki
2010-09-05 15:57                         ` Minchan Kim
2010-09-06  0:08                           ` KAMEZAWA Hiroyuki
2010-08-26  1:22     ` Pawel Osciak
2010-08-26  2:40     ` Michał Nazarewicz
2010-08-26  8:18       ` Peter Zijlstra
2010-08-26 10:18       ` Mel Gorman
2010-08-28 13:08     ` Hans Verkuil
2010-08-28 13:34       ` Peter Zijlstra
2010-08-28 13:58         ` Hans Verkuil
2010-08-28 14:16           ` Peter Zijlstra
2010-08-30  8:27     ` Clemens Ladisch
2010-08-26  1:28   ` Michał Nazarewicz
2010-08-26  8:17     ` Peter Zijlstra
2010-08-27  2:41       ` Michał Nazarewicz
2010-08-26 10:12   ` Mel Gorman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=op.vh0vbys97p4s8u@localhost \
    --to=m.nazarewicz@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).