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: Mon, 26 Mar 2007 23:43:08 +0200 [thread overview]
Message-ID: <E1HVwy4-0002UD-00@dorka.pomaz.szeredi.hu> (raw)
In-Reply-To: <20070326140036.f3352f81.akpm@linux-foundation.org> (message from Andrew Morton on Mon, 26 Mar 2007 14:00:36 -0700)
> > This patch makes writing to shared memory mappings update st_ctime and
> > st_mtime as defined by SUSv3:
>
> Boy this is complicated.
You tell me?
> Is there a simpler way of doing all this? Say, we define a new page flag
> PG_dirtiedbywrite and we do SetPageDirtiedByWrite() inside write() and
> ClearPageDirtiedByWrite() whenever we propagate pte-dirtiness into
> page-dirtiness. Then, when performing writeback we look to see if any of
> the dirty pages are !PageDirtiedByWrite() and, if so, we update [mc]time to
> current-time.
I don't think a page flag gains anything over the address_space flag
that this patch already has.
The complexity is not about keeping track of the "data modified
through mmap" state, but about msync() guarantees, that POSIX wants.
And these requirements do in fact make some sense: msync() basically
means:
"I want the data written through mmaps to be visible to the world"
And that obviously includes updating the timestamps.
So how do we know if the data was modified between two msync()
invocations? The only sane way I can think of is to walk the page
tables in msync() and test/clear the pte dirty bit.
Yes, this will make msync(MS_ASYNC) more heavyweight again. But if an
application doesn't want to update the timestamps, it should just omit
this call, since it does nothing else.
There shouldn't be any other side effect.
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>
next prev parent reply other threads:[~2007-03-26 21:43 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 [this message]
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
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=E1HVwy4-0002UD-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