On Mon, Jun 27, 2005 at 10:17:21PM -0400, Allen Briggs wrote:
> On Tue, Jun 28, 2005 at 10:35:55AM +0900, YAMAMOTO Takashi wrote:
> > it's too expensive and unreasonable to detect every actual read of
> > memory for atime update.
> > 
> > if you consider mmap for read as a lazy implementation of read(2),
> > it's appropriate to note it at mmap time.
> > 
> > talking about mtime, i think it can be noted when the changes are
> > flushed out to backing store.  ie. when we usually notice the dirtiness
> > of the pages.
> > updating mtime in VOP_GETPAGES is somewhat improper, IMO.
> 
> For whatever it's worth, I agree with all of the above.  To restate:
> 
> Update atime on mmap(...PROT_READ...)
> Update mtime when flushing dirty mmapped pages out to backing store.
> 
> I would expect neither more nor less.

updating mtime only when writing dirty pages to backing store seems
too late to me.  it seems wrong to make changes a file's data visible
to other threads without updating mtime.  that isn't how write() works,
and I don't think modifying a file via mmap() should start doing that.

currently, once a page is first faulted and the pmap-level mapping is created,
it can be modified again indefinitely without the kernel knowing and thus
without mtime being updated.  if this is a problem, then we could change
things so that making a clean page dirty again will cause another fault
to give us a chance to update mtime again.  we'll need that same refault-
on-redirty logic to do the fsync() optimizations that were discussed
some time back, so once we have that then we could also call back into
the fs to update mtime if we want.

-Chuck