Messages in this thread | | | Subject | Re: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) | From | James Bottomley <> | Date | 23 Aug 2003 17:21:21 -0500 |
| |
On Sat, 2003-08-23 at 16:43, David S. Miller wrote: > 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 :(
Could you elaborate some more? I agree that the MAP_PRIVATE mapping may not see cpu1's write because of cache incoherencies (but that's what I believe is covered by the `unspecified' bit of the MAP_PRIVATE definition above). MAP_PRIVATE is COW (i.e. the page is marked read only while it's shared), so there can be no data to flush in the cache for the page of the MAP_PRIVATE process...The only scenario I see where we can get cache based data destruction is if two cache aliases both contain dirty caches for the page (which can only happen for MAP_SHARED RW, which we already have the correct semantics for...they're racing to do a msync and the last one in wins).
James
- 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/
| |