Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934646AbYBAACd (ORCPT ); Thu, 31 Jan 2008 19:02:33 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S934525AbYBAACF (ORCPT ); Thu, 31 Jan 2008 19:02:05 -0500 Received: from host36-195-149-62.serverdedicati.aruba.it ([62.149.195.36]:48284 "EHLO mx.cpushare.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934372AbYBAACB (ORCPT ); Thu, 31 Jan 2008 19:02:01 -0500 Date: Fri, 1 Feb 2008 01:01:58 +0100 From: Andrea Arcangeli To: Christoph Lameter Cc: Robin Holt , Avi Kivity , Izik Eidus , kvm-devel@lists.sourceforge.net, Peter Zijlstra , steiner@sgi.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, daniel.blueman@quadrics.com Subject: Re: mmu_notifier: close hole in fork Message-ID: <20080201000158.GT7185@v2.random> References: <20080131045750.855008281@sgi.com> <20080131045812.785269387@sgi.com> <20080131123118.GK7185@v2.random> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2184 Lines: 54 On Thu, Jan 31, 2008 at 02:01:43PM -0800, Christoph Lameter wrote: > Talking to Robin and Jack we found taht we still have a hole during fork. > Fork may set a pte writeprotect. At that point the remote pte are > not marked readonly(!). Remote writes may occur to pages that are marked > readonly locally without this patch. Good catch! This was missing also in my #v5 (KVM doesn't need that because the only possible cows on sptes can be generated by ksm, but it would have been a problem for GRU). The more I think about it, the more I think GRU will run so nicely with follow_page taking zero additional locking and with the nicely scalable PT lock that doesn't require 1024 threads to trash on the same lock on 1024 different cpus if they access addresses that aren't in the same naturally aligned 2M chunk of virtual address space. I understood follow_page was performance critical for GRU, if yes, then I hope my _dual_ approach is by far the best for at least GRU (and KVM of course for the very same reason), and of course it'll fit XPMEM too the moment you add invalidate_range_start/end too. Signed-off-by: Andrea Arcangeli diff --git a/mm/memory.c b/mm/memory.c --- a/mm/memory.c +++ b/mm/memory.c @@ -494,6 +494,7 @@ static int copy_pte_range(struct mm_stru spinlock_t *src_ptl, *dst_ptl; int progress = 0; int rss[2]; + unsigned long start; again: rss[1] = rss[0] = 0; @@ -505,6 +506,7 @@ again: spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING); arch_enter_lazy_mmu_mode(); + start = addr; do { /* * We are holding two locks at this point - either of them @@ -525,6 +527,8 @@ again: } while (dst_pte++, src_pte++, addr += PAGE_SIZE, addr != end); arch_leave_lazy_mmu_mode(); + if (is_cow_mapping(vma->vm_flags)) + mmu_notifier(invalidate_pages, vma->vm_mm, start, addr); spin_unlock(src_ptl); pte_unmap_nested(src_pte - 1); add_mm_rss(dst_mm, rss[0], rss[1]); -- 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/