From: stepanm@codeaurora.org
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: zpfeffer@codeaurora.org, linux@arm.linux.org.uk,
ebiederm@xmission.com, linux-arch@vger.kernel.org,
dwalker@codeaurora.org, mel@csn.ul.ie,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, andi@firstfloor.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
Date: Tue, 20 Jul 2010 22:18:55 -0700 (PDT) [thread overview]
Message-ID: <5a63b73ff04b72db2930eae4e43e5c5b.squirrel@www.codeaurora.org> (raw)
> What is the problem about mapping a 1MB buffer with the DMA API?
>
> Possibly, an IOMMU can't find space for 1MB but it's not the problem of
the DMA API.
As you have pointed out, one of the issues is that allocation can fail.
While technically VCMM allocations can fail as well, these allocations can
be made from one or more memory pools that have been set aside
specifically to be used by devices. Thus, the kernel's normal allocator
will not encroach on the large physically-contiguous chunks (of size 1MB
or even 16MB) that are not easy to get back, and would be forced to deal
with increasing memory pressure in other ways.
Additionally, some of the memory pools may have special properties, such
as being part of on-chip memory with higher performance than regular
memory, and some devices may have special requirements regarding what type
or memory they need. The VCMM allocator solves the problem in a generic
way by being able to deal with multiple memory pools and supporting
prioritization schemes for which subset of the memory pools is to be used
for each physical allocation.
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
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>
next reply other threads:[~2010-07-21 5:18 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-21 5:18 stepanm [this message]
-- strict thread matches above, loose matches on Subject: below --
2010-07-06 15:42 [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management Zach Pfeffer
2010-07-03 5:38 Zach Pfeffer
2010-07-03 19:06 ` Eric W. Biederman
2010-07-07 22:44 ` Zach Pfeffer
2010-07-07 23:07 ` Russell King - ARM Linux
2010-07-08 23:59 ` Zach Pfeffer
2010-07-12 1:25 ` FUJITA Tomonori
2010-07-13 5:57 ` Zach Pfeffer
2010-07-13 6:03 ` FUJITA Tomonori
2010-07-13 12:14 ` Zach Pfeffer
2010-07-14 1:59 ` FUJITA Tomonori
2010-07-14 20:11 ` Zach Pfeffer
2010-07-14 22:05 ` Russell King - ARM Linux
2010-07-15 1:29 ` Zach Pfeffer
2010-07-15 1:47 ` Eric W. Biederman
2010-07-15 5:40 ` Zach Pfeffer
2010-07-15 5:35 ` Zach Pfeffer
2010-07-15 8:55 ` Russell King - ARM Linux
2010-07-16 0:48 ` Tim HRM
2010-07-16 7:58 ` Russell King - ARM Linux
2010-07-17 0:01 ` Larry Bassel
2010-07-19 9:21 ` Tim HRM
2010-07-21 0:44 ` Zach Pfeffer
2010-07-21 1:44 ` Timothy Meade
2010-07-22 4:06 ` Zach Pfeffer
2010-07-19 17:55 ` Michael Bohan
2010-07-19 18:40 ` Russell King - ARM Linux
2010-07-20 22:02 ` stepanm
2010-07-20 22:29 ` Russell King - ARM Linux
2010-07-21 5:49 ` Shilimkar, Santosh
2010-07-21 7:28 ` Russell King - ARM Linux
2010-07-21 7:45 ` Shilimkar, Santosh
2010-07-21 18:04 ` stepanm
2010-07-20 20:45 ` Zach Pfeffer
2010-07-20 20:54 ` Russell King - ARM Linux
2010-07-20 21:56 ` Zach Pfeffer
2010-07-19 6:52 ` Zach Pfeffer
2010-07-19 7:44 ` Eric W. Biederman
2010-07-22 4:25 ` Zach Pfeffer
2010-07-22 7:34 ` Russell King - ARM Linux
2010-07-22 16:25 ` Zach Pfeffer
2010-07-14 23:07 ` FUJITA Tomonori
2010-07-15 1:41 ` Zach Pfeffer
2010-07-19 8:22 ` Russell King - ARM Linux
2010-07-20 10:09 ` FUJITA Tomonori
2010-07-20 22:20 ` Zach Pfeffer
2010-07-21 1:44 ` FUJITA Tomonori
2010-07-22 4:30 ` Zach Pfeffer
2010-07-22 4:43 ` FUJITA Tomonori
2010-07-22 16:44 ` Zach Pfeffer
2010-07-22 7:39 ` Russell King - ARM Linux
2010-07-22 16:28 ` Zach Pfeffer
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=5a63b73ff04b72db2930eae4e43e5c5b.squirrel@www.codeaurora.org \
--to=stepanm@codeaurora.org \
--cc=andi@firstfloor.org \
--cc=dwalker@codeaurora.org \
--cc=ebiederm@xmission.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mel@csn.ul.ie \
--cc=zpfeffer@codeaurora.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).