Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261783AbUCKWUt (ORCPT ); Thu, 11 Mar 2004 17:20:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261790AbUCKWUt (ORCPT ); Thu, 11 Mar 2004 17:20:49 -0500 Received: from mx1.redhat.com ([66.187.233.31]:64460 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S261783AbUCKWUp (ORCPT ); Thu, 11 Mar 2004 17:20:45 -0500 Date: Thu, 11 Mar 2004 17:20:32 -0500 (EST) From: Rik van Riel X-X-Sender: riel@chimarrao.boston.redhat.com To: Hugh Dickins cc: Andrea Arcangeli , Ingo Molnar , Andrew Morton , , , William Lee Irwin III Subject: Re: anon_vma RFC2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1671 Lines: 42 On Thu, 11 Mar 2004, Hugh Dickins wrote: > length of your essay on vma merging, it strikes me that you've taken > a wrong direction in switching from my anon mm to your anon vma. > > Go by vmas and you have tiresome problems as they are split and merged, > very commonly. Plus you have the overhead of new data structure per vma. There's of course a blindingly simple alternative. Add every anonymous page to an "anon_memory" inode. Then everything is in effect file backed. Using the same page refcounting we already do, holes get shot into that "file". The swap cache code provides a filesystem like mapping from the anon_memory "files" to the on-disk stuff, or the anon_memory file pages are resident in memory. As a side effect, it also makes it possible to get rid of the swapoff code, simply move the anon_memory file pages from disk into memory... We can avoid BSD memory object like code by simply having multiple processes share the same anon_memory inode, allocating extents of virtual space at once to reduce VMA count. Not sure to which extent this is similar to what Hugh's stuff already does though, or if it's just a different way of saying how it's done ... I need to re-read the code ;) -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan - 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/