All of lore.kernel.org
 help / color / mirror / Atom feed
From: akepner@sgi.com
To: Roland Dreier <rdreier@cisco.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
	Tony Luck <tony.luck@intel.com>,
	Grant Grundler <grundler@parisc-linux.org>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	Jes Sorensen <jes@sgi.com>,
	Randy Dunlap <randy.dunlap@oracle.com>,
	David Miller <davem@davemloft.net>,
	Muli Ben-Yehuda <muli@il.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC/PARTIAL PATCH 0/3] dma: passing "attributes" to dma_map_* routines
Date: Wed, 9 Jan 2008 13:05:42 -0800	[thread overview]
Message-ID: <20080109210542.GP23661@sgi.com> (raw)
In-Reply-To: <adaprwa7lzd.fsf@cisco.com>

On Wed, Jan 09, 2008 at 01:00:38PM -0800, Roland Dreier wrote:
> .....
> The reason this hasn't been an issue until now is that almost all
> drivers work correctly if the Altix code just sets the "flush" bit for
> memory allocated via the consistent/coherent allocators.  However, if
> we want the device to write to userspace memory, this doesn't work
> (and mapping coherent memory allocated in the kernel into userspace is
> a mess on other platforms, because it unnecessarily consumes lowmem
> and/or kernel address space).
> 

And the only way that user level CQs work on Altix now is 
that we apply our own patches to allocate them in the 
kernel (with dma_alloc_coherent()) them mmap() them back 
to user space. A bug in one of these patches recently led  
to considerable drama with several customers - I'd love 
to get a fix in mainline so we can drop our patches and 
avoid the possibility such theatrics in the future ;-)

-- 
Arthur


  reply	other threads:[~2008-01-09 21:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-08  2:32 [RFC/PARTIAL PATCH 0/3] dma: passing "attributes" to dma_map_* routines akepner
2008-01-08 16:27 ` James Bottomley
2008-01-08 17:42   ` Roland Dreier
2008-01-08 17:54     ` James Bottomley
2008-01-08 18:05       ` Roland Dreier
2008-01-08 18:21         ` James Bottomley
2008-01-09  0:55           ` akepner
2008-01-09 21:00           ` Roland Dreier
2008-01-09 21:05             ` akepner [this message]
2008-01-09 21:30             ` James Bottomley
2008-01-11 18:20               ` Grant Grundler
2008-01-08 18:13   ` akepner
2008-01-08 17:50 ` Christoph Hellwig
2008-01-08 17:55   ` Roland Dreier
2008-01-08 18:23   ` akepner

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=20080109210542.GP23661@sgi.com \
    --to=akepner@sgi.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=davem@davemloft.net \
    --cc=grundler@parisc-linux.org \
    --cc=jbarnes@virtuousgeek.org \
    --cc=jes@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=muli@il.ibm.com \
    --cc=randy.dunlap@oracle.com \
    --cc=rdreier@cisco.com \
    --cc=tony.luck@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.