Mike Jagdis wrote:
>
...
> It's a while since I paid attention to the underlying architecture
> but I seem to remember back when I was doing the non-Intel support
> the 5x86/6x86 _didn't_ have cache line locking but it was promised
> for the 6x86MX.
I confirm that. Only the 6x86MX/MII has cache line locking.
>
> I did give some thought to possible uses though. Locking hot lines
> doesn't seem useful. If lines are hot they are going to tend to
> stay cached. If they aren't hot you probably have better things to
> do with your cache. This is not so true with a direct mapped cache
> because two, or more, hot locations can bounce a single cache line
> backwards and forwards but, I think, all the Cyrix L1 caches are
> associative (perhaps not the 5x86?) so it depends on the _exact_
> method the chip's internals use to allocate cache lines.
The 64Kb L1 cache in the 6x86MX is 4-way associative write-back. The
6x86MX also has a small 256 byte fully associative instruction line
cache.
>
> The only time I can think of where you have significant and
> _predictable_ trouble is when you want to read a region of memory
> which is large with respect to the cooler part of the cache in
> a linear and probably once only manner. Locking the cache lines
> which are going to be used again might help the chip make good
> decisions about which lines to use but how easy is it to figure
> out which lines they are? Is it possible to take a fault or
> interrupt while such an operation is in progress? If so you don't
> want to have significant amounts of L1 cache unavailable - especially
> if you could get rescheduled!
Hmmm. _Very_ interesting. I was thinking that perhaps the timer
interrupt code could be kept in such a locked cache line, because on a
busy machine it probably gets overwritten between the 10 ms periodic
interrupts. But that's a hypothesis. Nobody seems to have quantitative
data on this precise subject.
>
> My own feeling is that this is not so useful as it might appear
> at first glance. If you _really_ want to try something interesting
> why not write a gcc back end that uses a locked L1 line as a nice
> big register file and see if you can push the x86 architecture to
> new heights?
That's another very interesting possible application for the 6x86MX L1
cache locked lines. The x86 instruction set allows most instructions to
address memory instead of CPU registers, with no additional CPU clock
cycles.
Since the L1 cache is dual ported, works at the core clock speed and has
no more latencies than the usual x86 registers, locking a 1Kb region
could amount to having 256 general-purpose 32-bit registers.
When one realizes how much gymnastic gcc is forced to do because of the
scarcity of registers in the x86 architecture, one begins to wonder how
much of a performance gain one could get with 256 more registers.
Thanks for the tip :) Now who do I contact for more information on a
possible gcc x86 back end?
Cheers,
------------------------
André Balsa
andrebalsa@altern.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu