On Wed, Dec 04, 2002 at 10:41:31PM -0500, Jeff Garzik wrote:
> On Thu, Dec 05, 2002 at 01:38:47PM +1100, David Gibson wrote:
> > It seems the "try to get consistent memory, but otherwise give me
> > inconsistent" is only useful on machines which:
> > (1) Are not fully consisent, BUT
> > (2) Can get consistent memory without disabling the cache, BUT
> > (3) Not very much of it, so you might run out.
> >
> > The point is, there has to be an advantage to using consistent memory
> > if it is available AND the possibility of it not being available.
>
> Agreed here. Add to this
>
> (4) quite silly from an API taste perspective.
>
>
> > Otherwise, drivers which absolutely need consistent memory, no matter
> > the cost, should use consistent_alloc(), all other drivers just use
> > kmalloc() (or whatever) then use the DMA flushing functions which
> > compile to NOPs on platforms with consistent memory.
>
> Ug. This is travelling backwards in time.
>
> kmalloc is not intended to allocate memory for DMA'ing. I (and others)
> didn't spend all that time converting drivers to the PCI DMA API just to
> see all that work undone.
But if there aren't any consistency constraints on the memory, why not
get it with kmalloc(). There are two approaches to handling DMA on a
not-fully-consistent machine:
1) Allocate the memory specially so that it is consistent
2) Use any old memory, and make sure we have explicit cache
frobbing.
We have to have both: some hardware requires approach (1), and the
structure of the kernel often requires (2) to avoid lots of copying
(e.g. a network device doesn't allocate its own skbs to transmit, so
it can't assume the memory has any special consistency properties).
Since in case (2), we can't make assumptions about where the memory
came from, it might as well come from kmalloc() (or a slab, or
get_free_pages() or whatever).
-- David Gibson | For every complex problem there is a david@gibson.dropbear.id.au | solution which is simple, neat and | wrong. http://www.ozlabs.org/people/dgibson - 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/
This archive was generated by hypermail 2b29 : Sat Dec 07 2002 - 22:00:21 EST