gfp returns a page from a pool of pages.
If we would start out with an uncacheable region flagged as such, gfp
can return uncacheable pages just like it can return DMA-able pages.
The number of different "classes" of memory is growing rapidly. I am
suggesting to take a look at GFP, to see if it can be generalized to
the point where it can be useful for multiple DMA-capable ranged. Alan
says that there is a 27-bit limit for a certain sound-card. Sure.
There is a 32bit limit for many PCI cards. etc.
Alan suggests that we wait until we really hit the wall. I'm saying
I'd prefer to start looking for (general) solutions now (*).
Once gfp handles multiple, overlapping types of memory, it can easily
handle the pre-allocated uncacheable pages.
Now that last case is a bit special: You can create more of them on
demand. In fact, for lots of cases you can create more of them on
demand. For example, you can force a user-page into non-dma-able
memory if you're looking for a dma-albe page. So calling GFP you could
pass a flag saying "If not immediately available, try and get some
more". For DMA-able pages, that may mean swapping userpages to disk or
to "high" memory. For uncacheable pages, that may mean giving an empty
page a new, uncached mapping, and flushing the cache while we're at
it. Costly, but "you asked for it".
Roger.
(*) For example, redesigning now can cause a performance improvement.
Currently (IIRC) there is a big macro instantiated twice to handle DMA
or non-DMA memory. If we generalize this to handle many lists of free
pages, we'll move to just one instantiation of "grab a block from a
list". This is likely to have a smaller cache-footprint leading to a
performance improvement.
-- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* ------ Microsoft SELLS you Windows, Linux GIVES you the whole house ------
- 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/