Re: Cache incoherencies

Rogier Wolff (R.E.Wolff@BitWizard.nl)
Fri, 27 Aug 1999 16:00:42 +0200 (MEST)

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/