On Tue, 20 Sep 2005, Dominic Sweetman wrote: > > Besides new CPUs more often than not > > require changes to kernel-level software anyway. > > Making sure that isn't so is the reason why there's a MIPS32/64 spec > (with all the privileged operations defined). Which also avoids the > undesirable development step of new hardware combined with new kernel > software... Except that clairvoyance does not work reliably in the long run, so while you may be able to run old software with no changes on a new chip using a subset of its capabilities, you probably still want to update your kernel to better exploit the new design. > > I just disabled invalidations. ;-) > > Ouch. So the effect could have come from a variety of sources. Yes, I should have probably really done a better arrangement -- but I had limited time for testing, so I did just a rough estimate. I should get back to it eventually as that piece of code requires further tuning. > > Ironically this is where the write-back cache of the R4k gives loss > > rather than gain as compared to the write-through cache of the R3k > > (the system supports daughtercards with either CPU, so useful > > comparison is possible)... > > Maybe. But remember, on the R3K every write was a write through, and > they all had a cost in bus congestion, which may have delayed a > following read and held up the CPU (or the write buffer may have > filled and stalled the CPU). Effective bandwidth of DRAM memory for the system is documented to be 100MB/s and the R3k used (the PACEMIPS R3400) is clocked @40MHz (the R4400 on the other daughterboard is clocked @60MHz). Therefore while I believe congestion is indeed possible, it's not really that common with PIO, especially as the CPU has a priority over DMA traffic. Except from partial word writes which require RMW cycles at the memory controller level due to ECC (but they are not used for bulk transfers anyway). > I think up to about 33MHz write-through remained a tolerable policy > for 1988-era memory systems; any faster than that and you just sank > under a flood of writes. 2005-era memory systems are much faster when > bursting, but the time they take to process a single write cycle has > improved by less than 2x. So write-through is still a really bad idea > for 100MHz CPUs using off-chip memory. Certainly. It's just systems with a lot of DMA traffic do really beg for hardware-maintained coherence. > Even when your device requires you to push out all the data it can be > more efficient to write data to the cache and then force writeback to > memory: at least that way the data goes to the memory in efficient > burst cycles. That's assuming cache does write-allocation, which is not always the case. Maciej
