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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.