Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261631AbUCVCdM (ORCPT ); Sun, 21 Mar 2004 21:33:12 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261635AbUCVCdL (ORCPT ); Sun, 21 Mar 2004 21:33:11 -0500 Received: from mx1.redhat.com ([66.187.233.31]:742 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S261631AbUCVCdK (ORCPT ); Sun, 21 Mar 2004 21:33:10 -0500 Date: Sun, 21 Mar 2004 21:32:46 -0500 (EST) From: Rik van Riel X-X-Sender: riel@chimarrao.boston.redhat.com To: Andrea Arcangeli cc: Rajesh Venkatasubramanian , , , , , , , Subject: Re: [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix In-Reply-To: <20040322004652.GF3649@dualathlon.random> 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: 983 Lines: 24 On Mon, 22 Mar 2004, Andrea Arcangeli wrote: > It would be curious to test it after changing the return 1 to return 0 > in the page_referenced trylock failures? In the case of a trylock failure, it should probably return a random value. For heavily page faulting multithreaded apps, that would mean we'd tend towards random replacement, instead of FIFO. Then again, the locking problems shouldn't be too bad in most cases. If you're swapping the program will be waiting on IO and if it's not waiting on IO there's no problem. -- "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/