Re: [parisc-linux] Re: Problems with kernel mmap (failingtst-mmap-eofsync in glibc on parisc)

[James Bottomley]

On Fri, 2003-08-22 at 17:41, David S. Miller wrote:
> I think on parisc you are trying to avoid the write() case
> of the cache flush for non-shared mmap()s, and sorry you
> really can't do this, again this is:
> 
> 	When a write() system call occurs, the kernel "class" is writing to
> 	the page so all user mappings (shared or not!) need to be flushed
> 	out.
> 
> If your flush_dcache_page() is not doing this, it's no wonder
> the test case fails for you.

Yes, that's precisely what we're trying to do.  Our problem is that we
have to issue the flush to all the aliased addresses (one cache line at
a time) which is phenomenally expensive.

What we were hoping is that we could rely on this little property of
mmap:

       MAP_PRIVATE
                  Create a private copy-on-write mapping.  Stores
                  to the region do not affect the original  file.
                  It  is  unspecified whether changes made to the
                  file after the mmap call  are  visible  in  the
                  mapped region.

To avoid having to flush the non-shared mappings (basically on parisc if
you write to a file backing a MAP_PRIVATE mapping then we don't
guarantee you see the update).

I suppose if we had a way of telling if any of the i_mmap list members
were really MAP_SHARED semantics mappings, then we could alter our
flush_dcache_page() implementation to work.

James


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/