lkml.org 
[lkml]   [2003]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc)
On 22 Aug 2003 20:09:30 -0500
James Bottomley <James.Bottomley@SteelEye.com> wrote:

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

I thought about this very deeply last night and this morning.
And what you're trying to optimize won't work. Here is why.

If the first access to a MAP_PRIVATE mapping of a page is a read,
we'll use the page-cache page. This means that, with your
optimization, during this time if another cpu write()`s into the
page we'll lose the data update.

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

\
 
 \ /
  Last update: 2005-03-22 13:48    [W:0.082 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site