On 18.09.2015 08:34, Pavel Machek wrote:
Hi!
With this patch: => tftp 100000 big-40mb Speed: 1000, full duplex Using dwmac.ff702000 device TFTP from server 192.168.1.54; our IP address is 192.168.1.252 Filename 'big-40mb'. Load address: 0x100000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ########################## 7.6 MiB/s
A performance improvement of factor ~3.
Ok, so you turn on write-back cache and it is faster.
Its not only faster. My tests have shown, that the current implementation (WRITEALLOC) does not enable the dcache at all. No performance difference with dcache enable or disabled. I also tested this by removing the dcache flush and invalidate calls from the ethernet driver. And tftp still worked without any problems (same slow speed of course) with dcache enabled. On platforms with a really enabled dcache, such a change leads to a non-working network interface.
Yes, so we were running with dcache disabled, which can mask _many_ programming errors.
Of course.
Now... do you have an explanation why this is safe to do? Are there cache flushes that need to be added to the code now that we turned on write-back?
I have not found any issues yet with this patch added. The cache handling calls (flush, invalidate) are already included in the code using it (e.g. USB, ethernet, MMC).
For generic code, you are right.
What about socfpga-specific code? Will this still do the right thing with cache enabled? Do we have hardware registers mapped uncacheable?
Yes. Thats how it should be done for all platforms. Only for SDRAM dcache should be enabled. Otherwise we would run in many problems.
Ok, I guess we should enable the cache and fix any bugs currently hidden.
This is also my feeling. Such problems should show pretty quickly.
Thanks, Stefan