Re: spin_unlock optimization(i386)

Linus Torvalds (torvalds@transmeta.com)
Fri, 26 Nov 1999 10:56:40 -0800 (PST)


On Fri, 26 Nov 1999, Ingo Molnar wrote:
>
> So you and Manfred are right :) This means that the barrier changes in
> smp-2.3.30-A1 still hold, plus i believe all ioremapped area has to be
> made uncacheable on x86.

No, we don't want to make ioremapped memory uncacheable.

On x86 where x < 6, external logic makes sure that non-memory accesses are
uncached even if the page tables say otherwise (the KEN bit, I do
believe). There are known cases where the motherboard is broken, but they
are very few and worked around already.

On x86 where x >=6, the MTRR's do the same job. That's why the MTRR's were
introduced: because the P6 core can re-order accesses, you can no longer
afford to wait until the access hits the bus to know whether it is RAM or
not, so you have to introduce a in-core data structure to maintain that
knowledge.

So note that we do NOT want to make all ioremapped accesses uncacheable,
because then we could no longer do clever tricks with MTRR's.

And we know that we want to do MTRR stuff, at least eventually.

Linus

-
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/