Messages in this thread | | | Subject | Re: Cache incoherencies | Date | Fri, 27 Aug 1999 16:00:42 +0200 (MEST) | From | (Rogier Wolff) |
| |
Alan Cox wrote: > > > And the rest of that 4Mb range is loaded with critical data now running > > > uncached. Your box crawls like a 286. > > > > But you access it through the other window, which is still cached. > > Which as Russell says means you hack vmalloc().
Back to the start.
get_free_page now handles two different types of memory. DMA-able and non-DMA. Currently that suffices. The time will come pretty soon when however this is no longer sufficient. For example we'll be confronted with a 32-bit PCI card which can DMA into the lower 4G of memory pretty quickly.
We're in the process of getting "> 2G mem" support. This adds another class: bigmem.
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 think that generalizing gfp is a good idea in the end.
-- ** 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/
| |