Messages in this thread | | | Date | Fri, 20 Oct 2000 16:57:11 +0200 (CEST) | Subject | Re: 2.4.0-test10-pre3:Oops in mm/filemap.c:filemap_write_pa | From | Trond Myklebust <> |
| |
>>>>> " " == Alexander Viro <viro@math.psu.edu> writes:
> So what exactly do you want it to do when page is mapped by > user process? Should it remain visible or not? What should > happen if process writes to that page?
> Trond, I'm not asking about implementation - the question being > what semantics do you want for nfs_zap_caches() wrt user-mapped > pages.
For the general case of the page cache I think we can keep them quite simple:
+ We do in any case want to drop all pages that are unreferenced. (The reason for flushing may be that the file size has changed.)
+ For pages that are referenced (and unlocked) we would like to force them to get read in anew ASAP. How this is done in practice is irrelevant as far as NFS is concerned provided that we don't sleep on any I/O while in nfs_zap_caches()/invalidate_inode_pages().
The lower level stuff can and will sort out the business of flushing out pending writebacks that conflict with the read, so that isn't a problem for the VFS/VM.
The problem lies with writes that haven't yet been msync()ed (and hence do not have writebacks). For shared mappings, one should perhaps schedule an automatic msync() of the dirty pages (???). For private mappings, perhaps the best thing would be to defer the read?
Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |