Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753010Ab0AGWeZ (ORCPT ); Thu, 7 Jan 2010 17:34:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751456Ab0AGWeZ (ORCPT ); Thu, 7 Jan 2010 17:34:25 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:53249 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751259Ab0AGWeY (ORCPT ); Thu, 7 Jan 2010 17:34:24 -0500 Date: Thu, 7 Jan 2010 14:33:50 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Peter Zijlstra cc: Christoph Lameter , Arjan van de Ven , "Paul E. McKenney" , KAMEZAWA Hiroyuki , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "minchan.kim@gmail.com" , "hugh.dickins" , Nick Piggin , Ingo Molnar Subject: Re: [RFC][PATCH 6/8] mm: handle_speculative_fault() In-Reply-To: <1262900683.4049.139.camel@laptop> Message-ID: References: <20100104182429.833180340@chello.nl> <20100104182813.753545361@chello.nl> <20100105054536.44bf8002@infradead.org> <20100105192243.1d6b2213@infradead.org> <1262884960.4049.106.camel@laptop> <1262900683.4049.139.camel@laptop> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) 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: 1795 Lines: 41 On Thu, 7 Jan 2010, Peter Zijlstra wrote: > > I haven't yet looked at the patch, but isn't expand_stack() kinda like > what you want? That serializes using anon_vma_lock(). Yeah, that sounds like the right thing to do. It is the same operation, after all (and has the same effects, especially for the special case of upwards-growing stacks). So basically the idea is to extend that stack expansion to brk(), and possibly mmap() in general. Doing the same for munmap() (or shrinking thigns in general, which you can do with brk but not with the stack) is quite a bit harder. As can be seen by the fact that all the problems with the speculative approach are in the unmap cases. But the good news is that shrinking mappings is _much_ less common than growing them. Many memory allocators never shrink at all, or shrink only when they hit certain big chunks. In a lot of cases, the only time you shrink a mapping ends up being at the final exit, which doesn't have any locking issues anyway, since even if we take the mmap_sem lock for writing, there aren't going to be any readers possibly left. And a lot of growing mmaps end up just extending an old one. No, not always, but I suspect that if we really put some effort into it, we could probably make the write-lock frequency go down by something like an order of magnitude on many loads. Not all loads, no. Some loads will do a lot of file mmap's, or use MAP_FIXED and/or mprotect to split vma's on purpose. But that is certainly not likely to be the common case. 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/