This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] ppc32 dl-machine.c

Geoff Keating wrote:
> > Also, from the specification of the sync and isync instructions, it's clear
> > that the sync is needed.
> You'll have to explain that, I don't see it.

>From the 32-bit PEM (2002-02-21), description of isync (my emphasion):

The isync instruction provides an ordering function for the effects of all instructions
executed by a processor. Executing an isync instruction ensures that all instructions
preceding the isync instruction have completed before the isync instruction completes,

***except that memory accesses caused by those instructions need not have been performed
with respect to other processors and mechanisms.***

It also ensures that no subsequent
instructions are initiated by the processor until after the isync instruction completes.
Finally, it causes the processor to discard any prefetched instructions, with
the effect that
subsequent instructions will be fetched and executed in the context
established by the
instructions preceding the isync instruction. The isync instruction has no
effect on the other
processors or on their caches.

>From the 7410 UM (rev 0, 2000-10):

The sync after the icbi is required
to ensure that the icbi invalidation at the icache has completed.

The 7450 UM says the same.

>From the 750 UM (1999-02-23):

Special care must be taken to avoid coherency paradoxes in systems that
implement unified
secondary caches, and designers should carefully follow the guidelines for maintaining
cache coherency that are provided in the VEA, and discussed in Chapter 5,
“Cache Model
and Memory Coherency,” in The Programming Environments Manual. Because the 750
does not broadcast the M bit for instruction fetches, external caches are
subject to
coherency paradoxes.

(But the code example here does *not* include the sync, strangely enough).

> > icbi isn't broadcast on all systems, either...
> In that case, the kernel has to flush the whole icache when migrating
> processes.

Or we have to flush it in the code we're discussing here -- whichever is cheaper.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]