Messages in this thread | | | Date | Wed, 5 Mar 2003 08:43:33 +0100 | From | Rogier Wolff <> | Subject | Re: Proposal: Eliminate GFP_DMA |
| |
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. *************** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |