Curtis,
Many thanks, all is now clear....
On Mon, 24 Jul 2006, Curtis Monroe wrote:
> O_SYNC prevents Linux from caching the memory in its 16KB data cache.
Or to be slightly more pedantic "O_SYNC tells Linux to set the MMU
so that memory access don't use the hardware cache" :-)
> If you didn't use O_SYNC your first read would fill the data cache with this
> memory. you second read would just quickly grab the same copy of the data out
> of the data cache and not bother going to memory.
>
> If you don't specify O_SYNC Linux will guess what to do:
I'd missed this explanation from Jesse. And his explanation explains why
it might be hardware dependant! My ts7200 only has 32M SDRAM, and the
kernel "guessed" right.
I think there has been confusion over the many different
meanings/contexts/levels of "cache". It's an overused word :-)
cheers
Jim
> >From a previous post:
> "
> The TS7250 requires an extra option to the open("/dev/mem".. system call.
> The flags parameter must be O_RDWR|O_SYNC (not O_RDWR). Unless O_SYNC is
> specified, Linux arbitrarily decides whether or not an uncacheable MMU
> mapping is required based on the X86 specific notion of where the highest
> block of physical SDRAM is located. The TS-7250 w/64MB SDRAM has a block
> of memory in a high address which leads Linux to believe everything below it
> in physical space is also SDRAM and may also be mapped as cacheable.
>
> //Jesse Off
> "
>
> -Curtis.
>
> On July 24, 2006 09:10 am, Jim Jackson wrote:
> >
> > [aside: Guillermo, any chance you could not top post? It confuses
> > the discussion by putting you comments out of context.]
> >
> > On Mon, 24 Jul 2006, Guillermo Prandi wrote:
> >
> > > Jim, you are mixing the two problems.
> >
> > Actually No. My email was only concerning the "second" problem.
> > After having read up on "volatile" following my reading of the
> > Linux kernel email list thread on the topic, I believe I now understand
> > that issue.
> >
> > I am claiming the kernel does NO caching/buffering of /dev/mem
> > The only caching is hardware caching and I just don't understand the ARM
> > archecture enough to understand the hardware caching issues.
> >
> > > ....The compiler optimization
> > > problem and the kernel caching problem. Let's separate them to help
> > > you understand:
> > >
> > > 1) Compiler problem:
> > >
> > > In the code you presented, the compiler will generate good machine
> > > code. The problem would show up if you DON'T declare the pointers as
> > > volatile and use the code more than once, like in a loop:
> > >
> > > unsigned char *adc_io_stat;
> > > <...>
> > > do {
> > > s=*adc_io_stat & 0x80;
> > > } while( !s );
> >
> > Yes, but you claim their is additional kernel buffering/caching as well,
> > which I claim doesn't happen.
> >
> > But seeing as we seem to be having a mutual misunderstanding (common on
> > email/newsgroups) I'm going to bite the bullet and check this out once and
> > for all by resorting to reading the kernel source. I'll report back.
> >
> > >
> > >
> > >
> > >
> > >
> > > --- In Jim Jackson <> wrote:
> > > >
> > > >
> > > >
> > > > [re-ordered to remove the top posting]
> > > >
> > > > On Sun, 23 Jul 2006, Guillermo Prandi wrote:
> > > > > > On Sun, 23 Jul 2006, Guillermo Prandi wrote:
> > > > > > > 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.
> > > > > >
> > > > > 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).
> > > >
> > > > OK I'm genuinely trying to understand what you are saying here, so
> > > i'm
> > > > going to run thru' this stage by stage - because I'm not convinced.
> > > > I don't understand where your claimed "buffering" comes in,
> > > > /dev/mem is not a block device, we are not using read/write system
> > > calls
> > > > to read this file.
> > > >
> > > > Let's look at some code......
> > > >
> > > > volatile unsigned char *adc_io_cntl;
> > > > volatile unsigned char *adc_io_stat;
> > > > volatile unsigned char *adc_io_read;
> > > > int iofd;
> > > >
> > > > iofd=open("/dev/mem", O_RDWR);
> > > >
> > > > adc_io_stat=(unsigned char *)mmap(0,getpagesize(),
> > > > PROT_READ|PROT_WRITE,
> > > MAP_SHARED,iofd,0x10800000);
> > > >
> > > > s=*adc_io_stat & 0x80;
> > > >
> > > > Are you saying that this pointer dereference doesn't generate the
> > > correct
> > > > code to cause the hardware to read the relevant byte from the
> > > correct
> > > > memory location, that we are somehow reading a buffered copy of
> > > "memory"
> > > > instead of the real thing? And that somehow if we add O_SYNC to the
> > > open
> > > > then we read the real memory?
> > > >
> > > > Jim
> > > >
> > >
> > >
> > >
> > >
> > >
> >
>
------------------------ Yahoo! Groups Sponsor --------------------~-->
Something is new at Yahoo! Groups. Check out the enhanced email design.
http://us.click.yahoo.com/SISQkA/gOaOAA/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/
|