On Wed, Dec 04, 2002 at 07:44:17PM -0600, James Bottomley wrote:> david@gibson.dropbear.id.au said:> > Do you have an example of where the second option is useful? Off hand> > the only places I can think of where you'd use a consistent_alloc()> > rather than map_single() and friends is in cases where the hardware's> > behaviour means you absolutely positively have to have consistent> > memory. > > Well, it comes from parisc drivers. Here you'd really rather have> consistent memory because it's more efficient, but on certain> platforms it's just not possible.

Hmm... that doesn't seem sufficient to explain it.

Some background: I work with PPC embedded chips (the 4xx family) whoseonly way to get consistent memory is by entirely disabling the cache.However in some cases you *have* to have consistent memory despitethis very high cost. In all other cases you want to use inconsistentmemory (just allocated with kmalloc() or get_free_pages()) andexplicit cache flushes.

It seems the "try to get consistent memory, but otherwise give meinconsistent" is only useful on machines which: (1) Are not fully consisent, BUT (2) Can get consistent memory without disabling the cache, BUT (3) Not very much of it, so you might run out.

The point is, there has to be an advantage to using consistent memoryif it is available AND the possibility of it not being available.

Otherwise, drivers which absolutely need consistent memory, no matterthe cost, should use consistent_alloc(), all other drivers just usekmalloc() (or whatever) then use the DMA flushing functions whichcompile to NOPs on platforms with consistent memory.

Are there actually any machines with the properties described above?The machines I know about don't: - x86 and normal PPC are fully consistent, so the questiondoesn't arise - PPC 4xx and 8xx are incconsistent if cached, so you neverwant consistent if you don't absolutely need it - PA Risc is fully non-consistent (I'm told), so the questiondoesn't arise.