Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756261AbYAOUdE (ORCPT ); Tue, 15 Jan 2008 15:33:04 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752404AbYAOUcy (ORCPT ); Tue, 15 Jan 2008 15:32:54 -0500 Received: from viefep18-int.chello.at ([213.46.255.22]:7590 "EHLO viefep34-int.chello.at" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752272AbYAOUcx (ORCPT ); Tue, 15 Jan 2008 15:32:53 -0500 Subject: Re: [PATCH 0/2] Updating ctime and mtime for memory-mapped files [try #4] From: Peter Zijlstra To: Miklos Szeredi Cc: salikhmetov@gmail.com, 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, akpm@linux-foundation.org, protasnb@gmail.com In-Reply-To: References: <12004129652397-git-send-email-salikhmetov@gmail.com> Content-Type: text/plain Date: Tue, 15 Jan 2008 21:32:47 +0100 Message-Id: <1200429167.26045.45.camel@twins> Mime-Version: 1.0 X-Mailer: Evolution 2.21.5 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1979 Lines: 57 On Tue, 2008-01-15 at 21:27 +0100, Miklos Szeredi wrote: > > 1. Introduction > > > > This is the fourth version of my solution for the bug #2645: > > > > http://bugzilla.kernel.org/show_bug.cgi?id=2645 > > > > Changes since the previous version: > > > > 1) the case of retouching an already-dirty page pointed out > > by Miklos Szeredi has been addressed; > > I'm a bit sceptical, as we've also pointed out, that this is not > possible without messing with the page tables. > > Did you try my test program on the patched kernel? > > I've refreshed the patch, where we left this issue last time. It > should basically have equivalent functionality to your patch, and is a > lot simpler. There might be performance issues with it, but it's a > good starting point. It has the same problem as Anton's in that it won't get triggered again for an already dirty mapped page. But yeah, its simpler than fudging set_page_dirty(). > 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/