Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763688AbYARUXs (ORCPT ); Fri, 18 Jan 2008 15:23:48 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759067AbYARUXl (ORCPT ); Fri, 18 Jan 2008 15:23:41 -0500 Received: from smtp2.linux-foundation.org ([207.189.120.14]:59199 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759565AbYARUXk (ORCPT ); Fri, 18 Jan 2008 15:23:40 -0500 Date: Fri, 18 Jan 2008 12:22:25 -0800 (PST) From: Linus Torvalds To: Anton Salikhmetov cc: Miklos Szeredi , peterz@infradead.org, 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, akpm@linux-foundation.org, protasnb@gmail.com, r.e.wolff@bitwizard.nl, hidave.darkstar@gmail.com, hch@infradead.org Subject: Re: [PATCH -v6 2/2] Updating ctime and mtime for memory-mapped files In-Reply-To: <4df4ef0c0801181158s3f783beaqead3d7049d4d3fa7@mail.gmail.com> Message-ID: References: <12006091182260-git-send-email-salikhmetov@gmail.com> <1200651337.5920.9.camel@twins> <1200651958.5920.12.camel@twins> <4df4ef0c0801181158s3f783beaqead3d7049d4d3fa7@mail.gmail.com> User-Agent: Alpine 1.00 (LFD 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1222 Lines: 33 On Fri, 18 Jan 2008, Anton Salikhmetov wrote: > > The current solution doesn't hit the performance at all when compared to > the competitor POSIX-compliant systems. It is faster and does even more > than the POSIX standard requires. Your current patches have two problems: - they are simply unnecessarily invasive for a relatively simple issue - all versions I've looked at closer are buggy too Example: + if (pte_dirty(*pte) && pte_write(*pte)) + *pte = pte_wrprotect(*pte); Uhhuh. Looks simple enough. Except it does a non-atomic pte access while other CPU's may be accessing it and updating it from their hw page table walkers. What will happen? Who knows? I can see lost access bits at a minimum. IOW, this isn't simple code. It's code that it is simple to screw up. In this case, you really need to use ptep_set_wrprotect(), for example. So why not do it in many fewer lines with that simpler vma->dirty flag? Linus -- 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/