> On Fri, 2011-11-04 at 14:06 +0530, Suzuki Poulose wrote:
> > On 11/03/11 05:06, Josh Poimboeuf wrote:
> > > On Tue, 2011-10-25 at 17:23 +0530, Suzuki K. Poulose wrote:
> > > @@ -137,6 +137,9 @@ get_type:
> > > lwz r0, 8(r9) /* r_addend */
> > > add r0, r0, r3 /* final addend */
> > > stwx r0, r4, r7 /* memory[r4+r7]) = (u32)r0 */
> > > + dcbst r4,r7 /* flush dcache line to memory */
> > > + sync /* wait for flush to complete */
> > > + icbi r4,r7 /* invalidate icache line */
> >
> > Doing it this way has two drawbacks :
> >
> > 1) Placing it here in relocate would do the flushing for
> each and every update.
>
> I agree. My kernel had around 80,000 relocations, which means 80,000
> d-cache line flushes (for a 32k d-cache) and 80,000 i-cache line
> invalidates (for a 32k i-cache). Which is obviously a little
> overkill.
> Although I didn't notice a performance hit during boot.
The I-cache invalidates shouldn't be needed, the un-relocated
code can't be in the I-cache (on the grounds that executing
it would crash the system).
A single sync at the end is probably enough as well.
I guess it is possible for the cpu to prefetch/preload
into the i-cache through the jump into the relocated code?
So maybe a full i-cache invalidate right at the end? (or
a jump indirect? - which is probably there anyway)
The d-cache will need some kind of flush, since the modified
lines have to be written out, the only time it generates
additional memeory cycles are if there are two (or more)
reloations in the same d-cache line. Otherwise the early
write-back might help!
David
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
