From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, staubach@redhat.com,
hugh@veritas.com
Subject: Re: [patch 2/8] update ctime and mtime for mmaped write
Date: Tue, 06 Mar 2007 23:28:21 +0100 [thread overview]
Message-ID: <1173220101.6374.118.camel@twins> (raw)
In-Reply-To: <E1HOhzG-0006bd-00@dorka.pomaz.szeredi.hu>
On Tue, 2007-03-06 at 23:18 +0100, Miklos Szeredi wrote:
> > > None what so ever, but I always think of msync as a rare function
> > > (infrequent when compared to (minor) faults overall). But I don't have
> > > numbers backing that up either.
> > >
> > > Also, the radix tree scan you do isn't exactly cheap either.
> > >
> > > So what I was wondering is whether its worth optimizing this at the cost
> > > of another rmap walker. (one with very dubious semantics at that - it
> > > clears the pte dirty bit but doesn't particularly care about that nor
> > > does it respect the PG_dirty / PTE dirty relation)
> >
> > What this functionality requires is that MS_ASYNC is a full barrier wrt.
> > dirtyness. That is, we want to call set_page_dirty_mappig() as soon as
> > we touch a page in a dirtying fashion after MS_{,A}SYNC gets called.
> >
> > Hence we need the full page_mkclean() functionality, otherwise we don't
> > set AS_CMTIME again in time.
>
> AS_CMTIME is only for the case, when the "file modified since the last
> msync" info is lost from the ptes, e.g. because of page reclaim.
>
> So it doesn't matter if AS_CMTIME is not set, is_page_modified() will
> provide the necessary barrier.
The trouble is, we went from a pull to a push model, and now you're
adding pull code again.
We have PG_dirty correct at all times, I think its no less reasonable to
have AS_CMTIME correct in the same fashion.
next prev parent reply other threads:[~2007-03-06 22:29 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-06 18:04 [patch 0/8] VFS/VM patches Miklos Szeredi
2007-03-06 18:04 ` [patch 1/8] fix race in clear_page_dirty_for_io() Miklos Szeredi
2007-03-06 22:25 ` Andrew Morton
2007-03-06 18:04 ` [patch 2/8] update ctime and mtime for mmaped write Miklos Szeredi
2007-03-06 20:32 ` Peter Zijlstra
2007-03-06 21:24 ` Miklos Szeredi
2007-03-06 21:47 ` Peter Zijlstra
2007-03-06 22:00 ` Miklos Szeredi
2007-03-06 22:07 ` Peter Zijlstra
2007-03-06 22:18 ` Miklos Szeredi
2007-03-06 22:28 ` Peter Zijlstra [this message]
2007-03-06 22:36 ` Miklos Szeredi
2007-03-06 18:04 ` [patch 3/8] per backing_dev dirty and writeback page accounting Miklos Szeredi
2007-03-12 6:23 ` David Chinner
2007-03-12 11:40 ` Miklos Szeredi
2007-03-12 21:44 ` David Chinner
2007-03-12 22:36 ` Miklos Szeredi
2007-03-12 23:12 ` David Chinner
2007-03-13 8:21 ` Miklos Szeredi
2007-03-13 22:12 ` David Chinner
2007-03-14 22:09 ` Miklos Szeredi
2007-03-06 18:04 ` [patch 4/8] fix deadlock in balance_dirty_pages Miklos Szeredi
2007-03-06 18:04 ` [patch 5/8] fix deadlock in throttle_vm_writeout Miklos Szeredi
2007-03-06 18:04 ` [patch 6/8] balance dirty pages from loop device Miklos Szeredi
2007-03-06 18:04 ` [patch 7/8] add filesystem subtype support Miklos Szeredi
2007-03-06 18:04 ` [patch 8/8] consolidate generic_writepages and mpage_writepages fix Miklos Szeredi
2007-03-07 20:46 ` Andrew Morton
2007-03-07 21:26 ` Miklos Szeredi
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=1173220101.6374.118.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=hugh@veritas.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=staubach@redhat.com \
/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;
as well as URLs for NNTP newsgroup(s).