Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263149AbUCMSHj (ORCPT ); Sat, 13 Mar 2004 13:07:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263152AbUCMSHj (ORCPT ); Sat, 13 Mar 2004 13:07:39 -0500 Received: from ppp-217-133-42-200.cust-adsl.tiscali.it ([217.133.42.200]:54025 "EHLO dualathlon.random") by vger.kernel.org with ESMTP id S263149AbUCMSHg (ORCPT ); Sat, 13 Mar 2004 13:07:36 -0500 Date: Sat, 13 Mar 2004 19:08:18 +0100 From: Andrea Arcangeli To: Hugh Dickins Cc: Rik van Riel , Linus Torvalds , William Lee Irwin III , Ingo Molnar , Andrew Morton , Kernel Mailing List Subject: Re: anon_vma RFC2 Message-ID: <20040313180818.GM30940@dualathlon.random> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-GPG-Key: 1024D/68B9CB43 13D9 8355 295F 4823 7C49 C012 DFA1 686E 68B9 CB43 X-PGP-Key: 1024R/CB4660B9 CC A0 71 81 F4 A0 63 AC C0 4B 81 1D 8C 15 C8 E5 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2215 Lines: 41 On Sat, Mar 13, 2004 at 05:41:37PM +0000, Hugh Dickins wrote: > On Sat, 13 Mar 2004, Rik van Riel wrote: > > > > No, Linus is right. > > > > If a child process uses mremap(), it stands to reason that > > it's about to use those pages for something. > > > > Think of it as taking the COW faults early, because chances > > are you'd be taking them anyway, just a little bit later... > > Makes perfect sense in the read-write case. The read-only > case is less satisfactory, but those will be even rarer. overall it's not obvious to me that those will be even rarer. see the last email about kde-like usages to share data like-threads but with memory protection, those won't write to the data. I mean, it maybe the way to go, but I think we should get some ok from the major linux projects that we're not going to invalidate their smart optimizations first, and we should get this "misfeature" documented somehow. I've to admit the simplicity is appealing, but besides its coding-simplicity in practice I believe the only other appealing thing will be the fact it's not exploitable by people doing a flood of vma_splits, to solve that with anon_vma I'd need a prio tree on top of every anon_vma, that means even more memory wased both in the anon_vma and vma, though pratically a prio_tree there wouldn't be necessary. The anonmm solves the complexity issue using find_vma, so sharing the rbtree which already works. that's probably the part I find most appealing of anonmm. One can still exploit the complexity with anonmm too, but not from the same address space, so it's easier to limit with ulimit -u. I'm really not sure what's best, which is not good since I hoped to get anon_vma implementation working on Monday evening (heck it was already swapping fine my test app despite the huge vma_split/PageDirect bug that you noticed that probably caused `ps` to oops, I bet `ps` is doing a vma_split ;) but I now returned wondering about the design issues instead. - 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/