Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262064AbUDNXnw (ORCPT ); Wed, 14 Apr 2004 19:43:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262043AbUDNXkz (ORCPT ); Wed, 14 Apr 2004 19:40:55 -0400 Received: from ppp-217-133-42-200.cust-adsl.tiscali.it ([217.133.42.200]:16364 "EHLO dualathlon.random") by vger.kernel.org with ESMTP id S262065AbUDNXj2 (ORCPT ); Wed, 14 Apr 2004 19:39:28 -0400 Date: Thu, 15 Apr 2004 01:39:31 +0200 From: Andrea Arcangeli To: Hugh Dickins Cc: "Martin J. Bligh" , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: Benchmarking objrmap under memory pressure Message-ID: <20040414233931.GU2150@dualathlon.random> References: <20040414162700.GS2150@dualathlon.random> 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: 1301 Lines: 24 On Wed, Apr 14, 2004 at 06:48:40PM +0100, Hugh Dickins wrote: > This is just your guess at present, isn't it, Andrea? Any evidence? the evidence is pretty obvious, the single fact it's painful to remove the page_table_lock with anonmm around the vma manipulations, and the little benefit that the vma->page_table_lock provides with anonmm is quite a tangible measurements, I'm talking about the 256 ways here, any UP measurements is pretty useless. Last but not the least, you cannot know if any important app is going to be hurted with mremap doing copies and invalidating important optimizations for any application doing similar things that kde is doing to save memory and speedup startup times (we don't even know yet if kde itself is going to be hurted), you can take these risks with mainline, I cannot risk with -aa, and anon-vma provides other minor benefits too that we already discussed plus the IMHO important scalability point above. So I don't see why should mainline go with an inferior solution when I've already sorted out a better one. - 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/