This is the mail archive of the libc-alpha@sources.redhat.com 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


> Date: Fri, 27 Sep 2002 01:21:05 +0200
> From: Segher Boessenkool <segher@koffie.nl>

> 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.***
> 
...

Yes, but we don't care about other processors.  So long as the local
icache line is cleared at the point of the isync, and so long as the
icache line on other processors gets cleared sometime, everything will
work.  It's not like this code is (for instance) loading an object for
a thread running on another processor that could try to run the code
before a sync is executed.

> > > 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.

This code can't flush the icache on other processors if icbi isn't
broadcast; it doesn't have access to them.

-- 
- Geoffrey Keating <geoffk@geoffk.org>


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