The problem would not show up if your program reads or writes and
then exits (like to be used from a shell script); in such case cache
wouldn't apply (buffers are flushed on file close, i.e., on process
exit). The problem would only be noticed if reads/writes are repeated
within the same process, and before any automatic buffer flush
happens (because the kernel typically flushes the file buffers every
now and then). As for others not encountering the problem, I don't
know if they did, or did and not tell, or did and not even ask this
group! :)
Guille
--- In Jim Jackson <> wrote:
>
>
>
> 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 <jj@> 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 Sponsor --------------------~-->
Check out the new improvements in Yahoo! Groups email.
http://us.click.yahoo.com/6pRQfA/fOaOAA/yQLSAA/CFFolB/TM
--------------------------------------------------------------------~->
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/
|