linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Miklos Szeredi <miklos@szeredi.hu>
To: salikhmetov@gmail.com
Cc: miklos@szeredi.hu, linux-mm@kvack.org, jakob@unthought.net,
	linux-kernel@vger.kernel.org, valdis.kletnieks@vt.edu,
	riel@redhat.com, ksm@42.dk, staubach@redhat.com,
	jesper.juhl@gmail.com, torvalds@linux-foundation.org,
	a.p.zijlstra@chello.nl, akpm@linux-foundation.org,
	protasnb@gmail.com, r.e.wolff@bitwizard.nl,
	hidave.darkstar@gmail.com, hch@infradead.org
Subject: Re: [PATCH -v5 2/2] Updating ctime and mtime at syncing
Date: Thu, 17 Jan 2008 16:45:38 +0100	[thread overview]
Message-ID: <E1JFWvy-0006kJ-I2@pomaz-ex.szeredi.hu> (raw)
In-Reply-To: <4df4ef0c0801170540p36d3c566w973251527fc3bca1@mail.gmail.com> (salikhmetov@gmail.com)

> > I'm not sure this auto-updating is really needed (POSIX doesn't
> > mandate it).
> 
> Peter Shtaubach, author of the first solution for this bug,
> and Jacob Ostergaard, the reporter of this bug, insist the "auto-update"
> feature to be implemented.

Can they state their reasons for the insistence?

>  1) a base patch: update time just from fsync() and remove_vma()
>  2) update time on sync(2) as well
>  3) update time on MS_ASYNC as well

Oh, and the four-liner I posted the other day will give you 1) + 2) +
even more at a small fraction of the complexity.  And tacking on the
reprotect code will solve the MS_ASYNC issue just the same.

I agree, that having the timestamp updated on sync() is nice, and that
trivial patch will give you that, and will also update the timestamp
at least each 30 seconds if the file is being constantly modified,
even if no explicit syncing is done.

So maybe it's worth a little effort benchmarking how much that patch
affects the cost of writing to a page.

You could write a little test program like this (if somebody hasn't
yet done so):

 - do some preparation:

   echo 80 > dirty_ratio
   echo 80 > dirty_background_ratio
   echo 30000 > dirty_expire_centisecs
   sync

 - map a large file, one that fits comfortably into free memory
 - bring the whole file in, by reading a byte from each page
 - start the timer
 - write a byte to each page
 - stop the timer

It would be most interesting to try this on a filesystem supporting
nanosecond timestamps.  Anyone know which these are?

Miklos
----

Index: linux/mm/memory.c
===================================================================
--- linux.orig/mm/memory.c	2008-01-09 21:16:30.000000000 +0100
+++ linux/mm/memory.c	2008-01-15 21:16:14.000000000 +0100
@@ -1680,6 +1680,8 @@ gotten:
 unlock:
 	pte_unmap_unlock(page_table, ptl);
 	if (dirty_page) {
+		if (vma->vm_file)
+			file_update_time(vma->vm_file);
 		/*
 		 * Yes, Virginia, this is actually required to prevent a race
 		 * with clear_page_dirty_for_io() from clearing the page dirty
@@ -2313,6 +2315,8 @@ out_unlocked:
 	if (anon)
 		page_cache_release(vmf.page);
 	else if (dirty_page) {
+		if (vma->vm_file)
+			file_update_time(vma->vm_file);
 		set_page_dirty_balance(dirty_page, page_mkwrite);
 		put_page(dirty_page);
 	}


--
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:[~2008-01-17 15:45 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-17  0:57 [PATCH -v5 0/2] Updating ctime and mtime for memory-mapped files Anton Salikhmetov
2008-01-17  0:57 ` [PATCH -v5 1/2] Massive code cleanup of sys_msync() Anton Salikhmetov
2008-01-17 11:01   ` Miklos Szeredi
2008-01-17 11:47     ` Anton Salikhmetov
2008-01-17  0:57 ` [PATCH -v5 2/2] Updating ctime and mtime at syncing Anton Salikhmetov
2008-01-17 11:13   ` Miklos Szeredi
2008-01-17 12:16     ` Anton Salikhmetov
2008-01-17 12:45       ` Miklos Szeredi
2008-01-17 12:51         ` Rogier Wolff
2008-01-17 13:16         ` Anton Salikhmetov
2008-01-17 13:24           ` Rogier Wolff
2008-01-17 13:34             ` Anton Salikhmetov
2008-01-17 13:33           ` Miklos Szeredi
2008-01-17 13:40             ` Anton Salikhmetov
2008-01-17 15:45               ` Miklos Szeredi [this message]
2008-01-17 16:20                 ` Anton Salikhmetov
2008-01-17 16:26                   ` Miklos Szeredi
2008-01-17 16:33                     ` Anton Salikhmetov

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=E1JFWvy-0006kJ-I2@pomaz-ex.szeredi.hu \
    --to=miklos@szeredi.hu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=hidave.darkstar@gmail.com \
    --cc=jakob@unthought.net \
    --cc=jesper.juhl@gmail.com \
    --cc=ksm@42.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=protasnb@gmail.com \
    --cc=r.e.wolff@bitwizard.nl \
    --cc=riel@redhat.com \
    --cc=salikhmetov@gmail.com \
    --cc=staubach@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=valdis.kletnieks@vt.edu \
    /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