Messages in this thread | | | Date | Tue, 19 May 1998 16:07:37 -0100 | From | André Derrick Balsa <> | Subject | Re: Locking L1 cache lines in Cyrix 6x86MX CPUs |
| |
Hello Ralf,
ralf@uni-koblenz.de wrote: > > On Tue, May 19, 1998 at 10:24:43AM +0100, Mike Jagdis wrote: > > > 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? > > ... which somehow reminds of the Texas Instruments TMS 8900 used in the > TI99/4a, just that it had no cache and the register file was part of the > memory. Slow, especially when the memory bus is shared with the video > subsystem.
I designed a TMS9900 (not 8900, BTW) based motherboard at the time when it was the only 16-bit microprocessor available. Back then (1980-81) the bottleneck was the CPU, not the memory. Nowadays it's exactly the other way around.
> > Playing games with the cache is almost always a bad idea. The standard > lru or lru like replacement algorithems tend to be pretty good heuristics. > The cache locking feature is usually a candy added for sake of ``ultra > hard realtime'' apps for which cache line replacement would cause too much > jitter in the reaction times. Before that these guys often used to live > without caches for sake of consistent memory delays.
I think the point of locking cache lines is that a cache miss has a very high cost in terms of CPU clock cycles, because of the line refill latency.
But as suggested by Mike Jagdis, it could be a way to workaround one of the worst quirks of the x86 architecture: the scarcity of registers.
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
| |