MPC860 reorder and invalidate dcache

[Joakim Tjernlund]

>
> Every 15 minutes seems like lots of activity for flash.  Better do some
> math based upon your expected product lifetime and ensure the flash will
> work for that many write cycles.   A few milliseconds every 15 minutes
> doesn't seem to be worth special software.

You are rigth. I will check.
>
>
> > I read somewhere that the 'sync' instruction is an expensive one and I don't understand
> > why it's used it in invalidate_dcache_range()
>
> You are nit picking details that aren't likely to have any effect on your
> system performance.  You need to use 'sync' to ensure the processor pipelines
> are drained into cache before you push the lines to memory.  Ensure you have
> considered what will happen to your application after you completely invalidate
> the cache, as there is more stuff in there than the range of data buffers
> you are considering.  It isn't very costly to scan the cache and discover there
> isn't as much to be done.  It is more costly to invalidate lines you are using
> and reload them.

I do a lot of invalidate_dcache_range(). I have 2 mappings, one cached and one uncached. I
use the cached one when the FS  read data from the flash(this will burst read from
the flash). The other mapping is used for flash commands and to write data to flash.
Each time I read I do a invalidate_dcache_range() to pick up updates made from
the uncached mapping.

I was just hoping that the 'sync' instruction was an "accident", but now I know
better.

>
>
> > Our app consists of a lot of processes that mostly pass messages(UNIX sockets) between eachother.
> > Do you think it's better to run the CPU in 66/66 MHz or (as we do today) 80/40 MHz?
>
> You will have to test it with your application.  My experience has been the faster
> core speed was always the winner.

OK
>
> > Would the "pinned TLB" mode be helpful(we have plenty of memory,128MB)?
>
> Maybe.  Again you will have to test this.  With that much main memory it
> may not be helpful because you have to cover so much kernel space with
> page tables anyway.
OK

Thanks, for bearing with me.

      Jocke

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/