linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Miklos Szeredi <miklos@szeredi.hu>
To: akpm@linux-foundation.org
Cc: a.p.zijlstra@chello.nl, linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch resend v4] update ctime and mtime for mmaped write
Date: Tue, 27 Mar 2007 09:36:50 +0200	[thread overview]
Message-ID: <E1HW6Ec-0003Tv-00@dorka.pomaz.szeredi.hu> (raw)
In-Reply-To: <20070326232214.ee92d8c4.akpm@linux-foundation.org> (message from Andrew Morton on Mon, 26 Mar 2007 23:22:14 -0800)

> > > clear_page_dirty_for_io() already does that.
> > > 
> > > So we should be able to test PageDirtiedByWrite() after running
> > > clear_page_dirty_for_io() to discover whether this page was dirtied via
> > > MAP_SHARED, and then update the inode times if so.
> > 
> > What do you need the page flag for?
> 
> To work out whether the page was dirtied via write (in which case the
> timestamps were updated) or via mmap (in which case they were not).
> 
> >  The "modified through mmap" info
> > is there in the ptes.
> 
> It might not be there any more - the ptes could have got taken down by, for
> example, reclaim.

Yes, but then the "modified through mmap" is transferred to the
per-address_space flag.  All this is already done by this patch.

> I dunno - I'm not trying very hard.  I'm trying to encourage you to come up
> with something less costly and less complex than this thing, but you appear
> to be resisting.

No, I'm just arguing that your suggestion is actually a complication,
not a simplification ;)

> >  And from the ptes it can be transfered to a
> > per-address_space flag.  Nobody is interested through which page was
> > the file modified.
> > 
> > Anyway, that's just MS_SYNC.  MS_ASYNC doesn't walk the pages, yet it
> > should update the timestamp.  That's the difficult one.
> > 
> 
> We can treat MS_ASYNC as we treat MS_SYNC.  Then, MS_ASYNC *does* walk the
> pages.  Is does it in generic_writepages().  It also even walks the ptes
> for you, in clear_page_dirty_for_io().

Yes.  But that's not very useful semantic for MS_ASYNC vs. file time
update.

It would basically say:

  "if you cann MS_ASYNC, and the file was modified then sometime in
  the future you will get an updated c/mtime".

But this is not what POSIX says, and it's not what applications want.

For example "make" would want to know if a file was modified or not,
and with your suggestion only msync(MS_SYNC) would reliably provide
that info.  But msync(MS_SYNC) is unnecessary in many cases.

> There is surely no need to duplicate all that.

Yeah, we could teach generic_writepages() to conditionally not submit
for io just test/clear pte dirtyness.

Maybe that would be somewhat cleaner, dunno.

Then there are the ram backed filesystems, which don't have dirty
accounting and radix trees, and for which this pte walking is still
needed to provide semantics consistent with normal filesystems.

Miklos

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2007-03-27  7:36 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-25 21:10 Miklos Szeredi, Miklos Szeredi
2007-03-26 21:00 ` Andrew Morton
2007-03-26 21:10   ` Matt Mackall
2007-03-26 22:25     ` Andrew Morton
2007-03-26 21:43   ` Miklos Szeredi
2007-03-26 22:31     ` Andrew Morton
2007-03-27  6:55       ` Miklos Szeredi
2007-03-27  7:22         ` Andrew Morton
2007-03-27  7:36           ` Miklos Szeredi [this message]
2007-03-27  7:49             ` Andrew Morton
2007-03-27  8:03               ` Miklos Szeredi
2007-03-27  8:18                 ` Andrew Morton
2007-03-27  8:28                   ` Miklos Szeredi
2007-03-27  8:51                     ` Andrew Morton
2007-03-27  9:23                       ` Miklos Szeredi
2007-03-27 17:52                         ` Andrew Morton
2007-03-27 18:29                           ` Miklos Szeredi
     [not found] <20070327123422.d0bbc064.akpm@linux-foundation.org>
2007-03-27 20:09 ` linux
2007-03-27 20:31   ` Miklos Szeredi
2007-03-28  1:48     ` linux
2007-03-28  7:58       ` Nick Piggin
2007-03-28  9:50         ` linux
2007-03-29  4:59           ` Nick Piggin
2007-03-27 20:47   ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1HW6Ec-0003Tv-00@dorka.pomaz.szeredi.hu \
    --to=miklos@szeredi.hu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox