Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262240AbUCLQLK (ORCPT ); Fri, 12 Mar 2004 11:11:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262263AbUCLQLK (ORCPT ); Fri, 12 Mar 2004 11:11:10 -0500 Received: from fw.osdl.org ([65.172.181.6]:8680 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S262240AbUCLQLH (ORCPT ); Fri, 12 Mar 2004 11:11:07 -0500 Date: Fri, 12 Mar 2004 08:17:49 -0800 (PST) From: Linus Torvalds To: William Lee Irwin III cc: Andrea Arcangeli , Rik van Riel , Hugh Dickins , Ingo Molnar , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: anon_vma RFC2 In-Reply-To: <20040312124638.GR655@holomorphy.com> Message-ID: References: <20040311135608.GI30940@dualathlon.random> <20040312122127.GQ30940@dualathlon.random> <20040312124638.GR655@holomorphy.com> 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: 1614 Lines: 39 On Fri, 12 Mar 2004, William Lee Irwin III wrote: > > Absolute guarantees are nice but this characterization is too extreme. > The case where mremap() creates rmap_chains is so rare I never ever saw > it happen in 6 months of regular practical use and testing. Their > creation could be triggered only by remap_file_pages(). I have to _violently_ agree with Andrea on this one. The absolute _LAST_ thing we want to have is a "remnant" rmap infrastructure that only gets very occasional use. That's a GUARANTEED way to get bugs, and really subtle behaviour. I think Andrea is 100% right. Either do rmap for everything (like we do now, modulo IO/mlock), or do it for _nothing_. No half measures with "most of the time". Quite frankly, the stuff I've seen suggested sounds absolutely _horrible_. Special cases are not just a pain to work with, they definitely will cause bugs. It's not a matter of "if", it's a matter of "when". So let's make it clear: if we have an object-based reverse mapping, it should cover all reasonable cases, and in particular, it should NOT have rare fallbacks to code that thus never gets any real testing. And if we have per-page rmap like now, it should _always_ be there. You do have to realize that maintainability is a HELL of a lot more important than scalability of performance can be. Please keep that in mind. 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/