From: "Adam J. Richter" <adam@yggdrasil.com>
Date: Wed, 4 Dec 2002 21:20:49 -0800
Message-Id: <200212050520.VAA03472@adam.yggdrasil.com>
To: david@gibson.dropbear.id.au
Subject: Re: [RFC] generic device DMA implementation
Cc: davem@redhat.com, James.Bottomley@steeleye.com, jgarzik@pobox.com,
       linux-kernel@vger.kernel.org, miles@gnu.org
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1753
Lines: 43

At the risk of beating a dead horse, I'd like to clarify a potential
ambiguity.

David Gibson wrote:
>It seems the "try to get consistent memory, but otherwise give me
>inconsistent" 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 memory
>if it is available AND the possibility of it not being available.

	It is enough that there is an advantage to using consistent
memory on one platform (such as sparc64?) and the possibility of it
not being available on another platform (such as parisc), given that
you want the driver on both platforms (such as 53c700).  In that case,
we have identified three possible choices so far:

APPROACH				PROBLEMS

1. Use both memory allocators.		Increased source and object size,
   (as 53c700 currently does)		rarely used code branches, unneeded
					"if (!consistent)" tests on platforms
					where the answer is constant.

2. Assume only inconsistent memory.	Slower on platforms where consistent
					memory has speed advantage

3. Have "maybe consistent" allocation
   and {w,r}mb_maybe(addr,len) macros.


Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/