>>>>> " " == 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/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:16 EST