public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rogier Wolff <R.E.Wolff@BitWizard.nl>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Rogier Wolff <R.E.Wolff@BitWizard.nl>,
	Matthew Wilcox <willy@debian.org>, Andi Kleen <ak@suse.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Proposal: Eliminate GFP_DMA
Date: Wed, 5 Mar 2003 08:43:33 +0100	[thread overview]
Message-ID: <20030305084332.B22193@bitwizard.nl> (raw)
In-Reply-To: <1046819369.12226.34.camel@irongate.swansea.linux.org.uk>

On Tue, Mar 04, 2003 at 11:09:30PM +0000, Alan Cox wrote:
> On Tue, 2003-03-04 at 17:56, Rogier Wolff wrote:
> > All the modifier flags on kmalloc and GFP should be "memory allocation
> > descriptors".
> > A DMA pool descriptor will only point to pools that have that
> > capability.
> 
> Much much too simple. DMA to what from where for example ? Post 2.6 its
> IMHO a case of making the equivalent of pci_alloc_* pci_map_* work with
> generic device objects now we have them.

I can't think of a case that doesn't fit my model. So, if you're
saying that it's simple, that's good.

          dev1      +----------+        dev2
           |        |  CPU /   |         |
   --------+--------+  BRIDGE  +---------+--------
           |        |  ---->   |         |
          mem1      +----------+        mem2

If for example, there are two PCI busses, and a memory controller on
both of them, but no DMA cpability in one direction through the PCI 
bridge (embedded CPU) then there should be two memory pools. 

In the picture above: dev1 can reach mem2, but dev2 can't reach mem1.

PCI devices on the restricted PCI bus (dev2) will have to pass a 
memory allocation descriptor that describes just the memory on 
that PCI bus,  the other one (dev1) can pass a descriptor that 
prefers the non-shared memory, (leaving as much as possible for 
the devices on the other bus (bus2)), but
reverts to the memory that the other devices can handle as well. 

But if we end up "reading" from dev1, and writing the same data
to dev2 we're better off DMAing it to "mem2". So, how to tell
the dev1 driver that allocing off the allocation descriptor 
"mem1, then mem2", is not a good a good idea, and that it should
use "mem2, then mem1" is a problem that remains to be solved... 


But if I'm missing a case that can't be modelled, please enlighten
me as to what I'm missing.... 

			Roger.


-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an      * 
* excursion: The stable situation does not include humans. ***************

  reply	other threads:[~2003-03-05  7:33 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20030228064631.G23865@parcelfarce.linux.theplanet.co.uk.suse.lists.linux.kernel>
2003-02-28  8:56 ` Proposal: Eliminate GFP_DMA Andi Kleen
2003-02-28 14:12   ` Matthew Wilcox
2003-02-28 15:24     ` Alan Cox
2003-02-28 14:34       ` Matthew Wilcox
2003-02-28 15:55         ` Alan Cox
2003-02-28 14:56           ` Andi Kleen
2003-02-28 15:25             ` Jeff Garzik
2003-02-28 15:30               ` Andi Kleen
2003-02-28 15:34               ` Martin J. Bligh
2003-02-28 15:49                 ` Eli Carter
2003-02-28 16:03                   ` Russell King
2003-02-28 16:45                 ` Alan Cox
2003-02-28 15:31             ` Arjan van de Ven
2003-03-04 17:56           ` Rogier Wolff
2003-03-04 23:09             ` Alan Cox
2003-03-05  7:43               ` Rogier Wolff [this message]
2003-03-05 13:53                 ` Alan Cox
2003-02-28 15:44       ` Dmitry A. Fedorov
2003-02-28 15:58         ` Jeff Garzik
2003-02-28 18:17           ` Deepak Saxena
2003-02-28 18:27             ` Deepak Saxena
2003-02-28 19:52             ` Russell King
     [not found]           ` <mailman.1046456425.7772.linux-kernel2news@redhat.com>
2003-02-28 20:51             ` Pete Zaitcev
2003-02-28 22:11               ` Russell King
2003-02-28 16:05         ` Russell King
2003-02-28 17:27           ` Ivan Kokshaysky
2003-02-28 17:45         ` Alan Cox
2003-02-28  6:46 Matthew Wilcox

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=20030305084332.B22193@bitwizard.nl \
    --to=r.e.wolff@bitwizard.nl \
    --cc=ak@suse.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=willy@debian.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