Messages in this thread | | | Subject | Re: Cache incoherencies | Date | Fri, 27 Aug 1999 16:59:46 +0200 (MEST) | From | (Rogier Wolff) |
| |
Russell King wrote: > > Back to the start. > > Did you actually read any of my reasons for rejecting > the GFP solution? If so, you'd understand why it can't > be done. GFP_DMA does not fiddle with page bits. Some > architectures don't have page bits in the region that > GFP returns. Therefore you cannot change the cacheable > state. Therefore you cannot use this idea.
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/
| |