Hi Guillermo,
On Sun, 23 Jul 2006, Guillermo Prandi wrote:
> Hi, Jim: the volatile keyword is used to tell the compiler to avoid
> optimizing the access to that part of the memory, just like you said.
> However, that is a VERY special part of the memory: it is a file (/
> dev/mem) mapped into memory. As files are handled by the operating
> system and they are normally cached, you must tell the operating
> system not to cache the /dev/mem file accesses. That is what you say
> by using the O_SYNC flag in the open system call. If you omit the
> volatile keyword, the compiler might cache the access to the part of
> the memory where the file is mapped.
A little simplistically put - the "compiler" of course only generates
executable code from C source ;-) "cache" here only means the compiler
"may" optimise out actual pointer dereferences if it thinks there's
been no write and hence no data change.
> If you omit the O_SYNC keyword,
> the system would map a *buffer* to the /dev/mem file rather than to
> the actual memory (you could flush the buffers using the fcntl system
> call, but that just would be unpractical). The /dev/mem driver
> interprets the O_SYNC flag and makes use of the virtual memory mapper
> to map real memory locations into the user's virtual memory ranges.
All well and good, but why have I and others not found the caching
problem? Admittedly I've only used a TS7200, and I'm using an early
Technologics kernel.
> --- In Jim Jackson <> wrote:
> >
> >
> > >
> > > Hi again all, regarding this issue, something in the recently-
> posted
> > > thread 'Increasing kernel clock_tick' made me realise - the
> problem
> > > I'm getting is exactly the issue solved by the O_SYNC flag Peter
> > > Elliot mentions! http://www.simtec.co.uk/appnotes/AN0014/ notes
> this
> > > too -- I really was reading cached memory (as all the example
> code,
> > > including Jim Jackson's adio library do). Without the O_SYNC
> flag you
> > > get a cached representation of the IO...which gives exactly the
> > > symptoms I was observing!
> >
> > But it doesn't explain why I've not observed your symptoms!
> >
> > I had thought that using the C "volatile" sorted the problem with
> caching
> > issue. It may be alittle more complicated. Here's where my thinking
> is,
> > but I'm no expert in these areas, and would love someone to correct
> me.
> >
> > There was a recent thread on the linux kernel email list with
> subject
> > "[patch] spinlocks: remove 'volatile'" (see
> > http://www.gatago.com/linux/kernel/22508695.html) which certainly
> opened
> > my eyes as to what the C "volatile" really means - essentially it
> simple
> > is an indication to the compiler not to make certain assumptions
> about the
> > state of the variable/ptr etc when optimising. It means nothing
> guaranteed
> > in hardware terms.
> >
> > I suspect what is needed is some arm assembler macro to invalidate
> any
> > cached data for the relevant memory, then to read that memory
> > location to force a "real" read. I'm not sufficiantly up on arm
> > specifics to attempt this - Anybody else? It maybe that the O_SYNC
> flag
> > somehow forces this. Anyone know?
> >
> > Jim
> >
>
>
>
>
>
>
>
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|