From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: Dirty/Access bits vs. page content Date: Fri, 25 Apr 2014 15:51:01 +0200 Message-ID: <20140425135101.GE11096@twins.programming.kicks-ass.net> References: <1398389846.8437.6.camel@pasglop> <1398393700.8437.22.camel@pasglop> <5359CD7C.5020604@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org To: Hugh Dickins Cc: Linus Torvalds , "H. Peter Anvin" , Benjamin Herrenschmidt , Jan Kara , Dave Hansen , "linux-arch@vger.kernel.org" , linux-mm , Russell King - ARM Linux , Tony Luck List-Id: linux-arch.vger.kernel.org On Fri, Apr 25, 2014 at 05:01:23AM -0700, Hugh Dickins wrote: > One, regarding dirty shared mappings: you're thinking above of > mmap()'ing proper filesystem files, but this case also includes > shared memory - I expect there are uses of giant amounts of shared > memory, for which we really would prefer not to slow the teardown. > > And confusingly, those are not subject to the special page_mkclean() > constraints, but still need to be handled in a correct manner: your > patch is fine, but might be overkill for them - I'm not yet sure. I think we could look at mapping_cap_account_dirty(page->mapping) while holding the ptelock, the mapping can't go away while we hold that lock. And afaict that's the exact differentiator between these two cases. > Two, Ben said earlier that he's more worried about users of > unmap_mapping_range() than concurrent munmap(); and you said > earlier that you would almost prefer to have some special lock > to serialize with page_mkclean(). > > Er, i_mmap_mutex. > > That's what unmap_mapping_range(), and page_mkclean()'s rmap_walk, > take to iterate over the file vmas. So perhaps there's no race at all > in the unmap_mapping_range() case. And easy (I imagine) to fix the > race in Dave's racewrite.c use of MADV_DONTNEED: untested patch below. Ooh shiney.. yes that might work! > But exit and munmap() don't take i_mmap_mutex: perhaps they should > when encountering a VM_SHARED vma Well, they will of course take it in order to detach the vma from the rmap address_space::i_mmap tree. > (I believe VM_SHARED should be > peculiar to having vm_file seta, but test both below because I don't > want to oops in some odd corner where a special vma is set up). I think you might be on to something there... -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([198.137.202.9]:49606 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752074AbaDYNvM (ORCPT ); Fri, 25 Apr 2014 09:51:12 -0400 Date: Fri, 25 Apr 2014 15:51:01 +0200 From: Peter Zijlstra Subject: Re: Dirty/Access bits vs. page content Message-ID: <20140425135101.GE11096@twins.programming.kicks-ass.net> References: <1398389846.8437.6.camel@pasglop> <1398393700.8437.22.camel@pasglop> <5359CD7C.5020604@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Hugh Dickins Cc: Linus Torvalds , "H. Peter Anvin" , Benjamin Herrenschmidt , Jan Kara , Dave Hansen , "linux-arch@vger.kernel.org" , linux-mm , Russell King - ARM Linux , Tony Luck Message-ID: <20140425135101.XWYxl_uvGPvAsA2TWOxpY1wE4TpJD99NHJ7lizpJTSA@z> On Fri, Apr 25, 2014 at 05:01:23AM -0700, Hugh Dickins wrote: > One, regarding dirty shared mappings: you're thinking above of > mmap()'ing proper filesystem files, but this case also includes > shared memory - I expect there are uses of giant amounts of shared > memory, for which we really would prefer not to slow the teardown. > > And confusingly, those are not subject to the special page_mkclean() > constraints, but still need to be handled in a correct manner: your > patch is fine, but might be overkill for them - I'm not yet sure. I think we could look at mapping_cap_account_dirty(page->mapping) while holding the ptelock, the mapping can't go away while we hold that lock. And afaict that's the exact differentiator between these two cases. > Two, Ben said earlier that he's more worried about users of > unmap_mapping_range() than concurrent munmap(); and you said > earlier that you would almost prefer to have some special lock > to serialize with page_mkclean(). > > Er, i_mmap_mutex. > > That's what unmap_mapping_range(), and page_mkclean()'s rmap_walk, > take to iterate over the file vmas. So perhaps there's no race at all > in the unmap_mapping_range() case. And easy (I imagine) to fix the > race in Dave's racewrite.c use of MADV_DONTNEED: untested patch below. Ooh shiney.. yes that might work! > But exit and munmap() don't take i_mmap_mutex: perhaps they should > when encountering a VM_SHARED vma Well, they will of course take it in order to detach the vma from the rmap address_space::i_mmap tree. > (I believe VM_SHARED should be > peculiar to having vm_file seta, but test both below because I don't > want to oops in some odd corner where a special vma is set up). I think you might be on to something there...