In article <20010605155550.C22741@metastasis.f00f.org>,
Chris Wedgwood <cw@f00f.org> wrote:
>On Mon, Jun 04, 2001 at 07:03:01PM -0700, David S. Miller wrote:
>
> The x86 doesn't have dumb caches, therefore it really doesn't
> need to flush anything. Maybe a mb(), but that is it.
>
>What if the memory is erased underneath the CPU being aware of this?
>In such a way ig generates to bus traffic...
Doing bank switching etc is outside the scope of the current DMA cache
flush macros - they are there only for "sane" cache coherency issues,
not to be used as generic "we have to flush the cache because we went
behind the back of the CPU and switched a bank of memory around".
You will have to come up with some new primitive for this.
The x86 has the "wbinval" instruction, although it should be noted that
- it is buggy and will lock up some CPU's. Use with EXTREME CAUTION.
Intel set a special field in the MP table for whether wbinval is
usable or not, and you can probably find their errata on which CPU's
it doesn't work on (I think it was some early PPro steppings).
When wbinval doesn't work, there's another strategy to flush the
cache, but I forget what it was. It was something ridiculous like
reading in a few megabytes of memory from consecutive physical
addresses to make sure that the cache has been replaced.
- even when it works, it is necessarily very very very slow. Not to be
used lightly. As you can imagine, the work-around is even slower.
On the whole, I would suggest avoiding this like the plague, and just
marking such memory to be non-cacheable, regardless of whether there is
a performance impact or not. If you mark it write-combining and
speculative, it's going to perform a bit better.
Linus
-
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/
This archive was generated by hypermail 2b29 : Thu Jun 07 2001 - 21:00:34 EST