linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Zach Pfeffer <zpfeffer@codeaurora.org>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: linux@arm.linux.org.uk, alan@lxorguk.ukuu.org.uk,
	randy.dunlap@oracle.com, dwalker@codeaurora.org, mel@csn.ul.ie,
	linux-arm-msm@vger.kernel.org, joro@8bytes.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 3/3] mm: iommu: The Virtual Contiguous Memory Manager
Date: Wed, 21 Jul 2010 20:50:26 -0700	[thread overview]
Message-ID: <20100722035026.GB14176@codeaurora.org> (raw)
In-Reply-To: <20100714105922D.fujita.tomonori@lab.ntt.co.jp>

On Wed, Jul 14, 2010 at 10:59:43AM +0900, FUJITA Tomonori wrote:
> On Tue, 13 Jul 2010 10:02:23 +0100
> 
> Zach Pfeffer said this new VCM infrastructure can be useful for
> video4linux. However, I don't think we need 3,000-lines another
> abstraction layer to solve video4linux's issue nicely.

Its only 3000 lines because I haven't converted the code to use
function pointers.

> I can't find any reasonable reasons that we need to merge VCM; seems
> that the combination of the current APIs (or with some small
> extensions) can work for the issues that VCM tries to solve.

Getting back to the point. There is no API that can handle large
buffer allocation and sharing with low-level attribute control for
virtual address spaces outside the CPU. At this point if you need to
work with big buffers, 1 MB and 16 MB etc, and map those big buffers
to non-CPU virtual spaces you need to explicitly carve them out and
set up the mappings and sharing by hand. Its reasonable to have an API
that can do this especially since IOMMUs are going to become more
prevalent. The DMA API et al. take a CPU centric view of virtual space
management, sharing has to be explicitly written and external virtual
space management is left up to device driver writers. Given a system
where each device has an IOMMU or a MMU the whole concept of a
scatterlist goes away. The VCM API gets a jump on it.

--
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  3:50 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-30  5:55 [RFC 1/3] mm: iommu: An API to unify IOMMU, CPU and device memory management Zach Pfeffer
2010-06-30  5:55 ` [RFC 2/3] mm: iommu: A physical allocator for the VCMM Zach Pfeffer
2010-06-30  5:55 ` [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager Zach Pfeffer
2010-07-01 17:17   ` Randy Dunlap
2010-07-01 18:02     ` Andi Kleen
2010-07-01 19:28       ` Daniel Walker
2010-07-01 19:38         ` Andi Kleen
2010-07-01 19:42           ` Daniel Walker
2010-07-01 22:15             ` Hari Kanigeri
2010-07-02  7:09               ` Zach Pfeffer
2010-07-10 14:36                 ` Joerg Roedel
2010-07-13  5:21                   ` Zach Pfeffer
2010-07-14 19:34                     ` Joerg Roedel
2010-07-15  1:18                       ` Zach Pfeffer
2010-07-01 22:00           ` Zach Pfeffer
2010-07-01 22:05             ` Daniel Walker
2010-07-02  7:33               ` Zach Pfeffer
2010-07-10 14:56                 ` Joerg Roedel
2010-07-13  5:46                   ` Zach Pfeffer
2010-07-13  5:59                     ` FUJITA Tomonori
2010-07-13  8:20                       ` Alan Cox
2010-07-13  8:30                         ` FUJITA Tomonori
2010-07-13  8:42                           ` Alan Cox
2010-07-13  8:45                             ` FUJITA Tomonori
2010-07-13  9:02                               ` Russell King - ARM Linux
2010-07-14  1:59                                 ` FUJITA Tomonori
2010-07-22  3:50                                   ` Zach Pfeffer [this message]
2010-07-22  4:47                                     ` FUJITA Tomonori
2010-07-22 16:33                                       ` Zach Pfeffer
2010-07-22  7:51                                     ` Russell King - ARM Linux
2010-07-22 16:13                                       ` Zach Pfeffer
2010-07-13 12:06                       ` Zach Pfeffer
2010-07-01 22:51             ` Hari Kanigeri
2010-07-02  7:29               ` Zach Pfeffer
2010-07-01 23:00             ` Andi Kleen
2010-07-02  6:17               ` Zach Pfeffer
2010-07-02  8:22                 ` Andi Kleen
2010-07-02 18:42                   ` Zach Pfeffer
2010-07-10 15:11                 ` Joerg Roedel
2010-07-13  5:52                   ` Zach Pfeffer
2010-07-03  6:36               ` Zach Pfeffer
2010-07-10 14:54             ` Joerg Roedel
2010-07-13  5:27               ` Zach Pfeffer
2010-07-01 20:59     ` Paul Walmsley
2010-07-01 21:48       ` Randy Dunlap
2010-06-30 23:40 ` [RFC 1/3] mm: iommu: An API to unify IOMMU, CPU and device memory management Randy Dunlap
2010-07-01  7:16   ` Zach Pfeffer
2010-07-02  7:00     ` Paul Mundt

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=20100722035026.GB14176@codeaurora.org \
    --to=zpfeffer@codeaurora.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andi@firstfloor.org \
    --cc=dwalker@codeaurora.org \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=joro@8bytes.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=randy.dunlap@oracle.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;
as well as URLs for NNTP newsgroup(s).