Messages in this thread | | | Date | Sat, 23 Aug 2003 14:43:30 -0700 | From | "David S. Miller" <> | Subject | Re: [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/
| |