>I think we should take a step back, abstract the GFP mechansism to the
>point where it can satisfy a "gimmy any page" request, which
>technically turns into "preferably a page from non-DMA memory, but if
>you're out of those, give me a DMA-able page".
>
>A driver wanting to do DMA will request "a DMA-ABLE page" (with either
>the 16M ISA limit, the 1M XT limit, or the 4G PCI limit!), with "if
>you're out of those, give up".
>
>I think that GFP may need to be redesigned one time or another.
>However, once that is done, taking along things as "uncached" pages,
>should become a breeze. Yes, the current implementation makes it a
>quick hack to vmalloc.
I beleive we should not confuse DMA-able and unached. DMA can be
perfectly fine on cachable memory on a non-coherent architecture if you
do the appropriate flush when needed. Making all DMA memory non-cachable
would have a huge performance hit on some platform.
>I think that generalizing gfp is a good idea in the end.
I'll let more competent people handle this and keep my vmalloc stuff for
now ;-)
--
Perso. e-mail: <mailto:bh40@calva.net>
Work e-mail: <mailto:benh@mipsys.com>
BenH. Web : <http://calvaweb.calvacom.fr/bh40/>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/