linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
To: m.szyprowski@samsung.com
Cc: fujita.tomonori@lab.ntt.co.jp, corbet@lwn.net,
	m.nazarewicz@samsung.com, linux-mm@kvack.org,
	p.osciak@samsung.com, xiaolin.zhang@intel.com, hvaibhav@ti.com,
	robert.fekete@stericsson.com, marcus.xm.lorentzon@stericsson.com,
	linux-kernel@vger.kernel.org, kyungmin.park@samsung.com
Subject: RE: [PATCH 2/4] mm: cma: Contiguous Memory Allocator added
Date: Thu, 22 Jul 2010 18:35:07 +0900	[thread overview]
Message-ID: <20100722183432U.fujita.tomonori@lab.ntt.co.jp> (raw)
In-Reply-To: <000001cb296f$6eba8fa0$4c2faee0$%szyprowski@samsung.com>

On Thu, 22 Jul 2010 09:28:02 +0200
Marek Szyprowski <m.szyprowski@samsung.com> wrote:

> > About the framework, it looks too complicated than we actually need
> > (the command line stuff looks insane).
> 
> Well, this command line stuff was designed to provide a way to configure
> memory allocation for devices with very sophisticated memory requirements.

You have the feature in the wrong place.

Your example: a camera driver and a video driver can share 20MB, then
they want 20MB exclusively.

You can reserve 20MB and make them share it. Then you can reserve 20MB
for both exclusively.

You know how the whole system works. Adjust drivers (probably, with
module parameters).


> > Why can't we have something simpler, like using memblock to reserve
> > contiguous memory at boot and using kinda mempool to share such memory
> > between devices?
> 
> There are a few problems with such simple approach:
> 
> 1. It does not provide all required functionality for our multimedia
> devices. The main problem is the fact that our multimedia devices
> require particular kind of buffers to be allocated in particular memory
> bank. Then add 2 more requirements: a proper alignment (for some of them
> it is even 128Kb) and particular range of addresses requirement (some
> buffers must be allocated at higher addresses than the firmware).
> This is very hard to achieve with such simple allocator.

When a video driver needs 20MB to work properly, what's the point of
releasing the 20MB for others then trying to get it again later?

Even with the above example (two devices never use the memory at the
same time), the driver needs memory regularly. What's the point of
split the 20MB to small chunks and allocate them to others?

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-07-22  9:35 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-20 15:51 [PATCH 0/4] The Contiguous Memory Allocator Michal Nazarewicz
2010-07-20 15:51 ` [PATCH 1/4] lib: rbtree: rb_root_init() function added Michal Nazarewicz
2010-07-20 15:51   ` [PATCH 2/4] mm: cma: Contiguous Memory Allocator added Michal Nazarewicz
2010-07-20 15:51     ` [PATCH 3/4] mm: cma: Test device and application added Michal Nazarewicz
2010-07-20 15:51       ` [PATCH 4/4] arm: Added CMA to Aquila and Goni Michal Nazarewicz
2010-07-20 18:15     ` [PATCH 2/4] mm: cma: Contiguous Memory Allocator added Daniel Walker
2010-07-20 19:14       ` Michał Nazarewicz
2010-07-20 19:38         ` Daniel Walker
2010-07-21 12:01           ` Michał Nazarewicz
2010-07-21 17:35             ` Daniel Walker
2010-07-21 18:11               ` Michał Nazarewicz
2010-07-21 18:19                 ` Daniel Walker
2010-07-21 18:38                   ` Michał Nazarewicz
2010-07-21 18:58                     ` Daniel Walker
2010-07-21 19:21                       ` Michał Nazarewicz
2010-07-21 19:37                         ` Daniel Walker
2010-07-21 19:53                           ` Michał Nazarewicz
2010-07-21 20:03                             ` Daniel Walker
2010-07-21 20:22                               ` Michał Nazarewicz
2010-07-21 20:34                                 ` Daniel Walker
2010-07-21 20:43                                   ` Michał Nazarewicz
2010-07-21 20:45                                     ` Daniel Walker
2010-07-21 20:56                                       ` Michał Nazarewicz
2010-07-21 21:01                                         ` Daniel Walker
2010-07-22  9:34                                           ` Michał Nazarewicz
2010-07-21 13:52         ` Mark Brown
2010-07-21 14:31           ` Michał Nazarewicz
2010-07-21 18:24             ` Mark Brown
2010-07-21 18:41               ` Michał Nazarewicz
2010-07-22  9:06                 ` Mark Brown
2010-07-22  9:25                   ` Marek Szyprowski
2010-07-22 10:52                     ` Mark Brown
2010-07-22 11:30                       ` Michał Nazarewicz
2010-07-22 12:46                         ` Mark Brown
2010-07-22 13:24                           ` Michał Nazarewicz
2010-07-22 13:40                             ` Mark Brown
2010-07-22 14:58                               ` Michał Nazarewicz
2010-07-22 15:05                                 ` Mark Brown
2010-07-20 20:52     ` Jonathan Corbet
2010-07-21 10:16       ` Michał Nazarewicz
2010-07-21  0:12     ` Jonathan Corbet
2010-07-22  5:37       ` FUJITA Tomonori
2010-07-22  7:28         ` Marek Szyprowski
2010-07-22  9:35           ` FUJITA Tomonori [this message]
2010-07-22  9:50             ` Michał Nazarewicz
2010-07-22 10:17               ` FUJITA Tomonori
2010-07-22 10:55                 ` Mark Brown
2010-07-22 11:49                 ` Michał Nazarewicz
2010-07-22  4:54     ` Zach Pfeffer
2010-07-22  7:49       ` Marek Szyprowski
2010-07-23  7:06       ` Pawel Osciak

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=20100722183432U.fujita.tomonori@lab.ntt.co.jp \
    --to=fujita.tomonori@lab.ntt.co.jp \
    --cc=corbet@lwn.net \
    --cc=hvaibhav@ti.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=m.nazarewicz@samsung.com \
    --cc=m.szyprowski@samsung.com \
    --cc=marcus.xm.lorentzon@stericsson.com \
    --cc=p.osciak@samsung.com \
    --cc=robert.fekete@stericsson.com \
    --cc=xiaolin.zhang@intel.com \
    /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