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 22:47:01 +0100 [thread overview]
Message-ID: <1173217621.4718.27.camel@lappy> (raw)
In-Reply-To: <E1HOh8r-0006Sp-00@dorka.pomaz.szeredi.hu>
On Tue, 2007-03-06 at 22:24 +0100, Miklos Szeredi wrote:
> > I'm not liking this, its not a constant operation as the name implies.
>
> OK, I'll think of something better.
>
> > And it style is a bit out of line with the rest of rmap.
> >
> > The thing it actually does is page_mkclean(), all it doesn't do is
> > setting the pte read-only.
> >
> > I can understand you wanting to avoid the overhead of the minor faults
> > resulting from using page_mkclean(), but I'm not sure its worth it.
>
> It would be nice if the cost of MS_ASYNC wouldn't be too high. And I
> do have the feeling that minor faults are far more expensive than
> cleaning the dirty bit in the ptes.
>
> Do you have any numbers?
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)
next prev parent reply other threads:[~2007-03-06 21:47 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 [this message]
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
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=1173217621.4718.27.camel@lappy \
--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.