Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 1 Sep 2002 17:25:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 1 Sep 2002 17:25:31 -0400 Received: from humbolt.nl.linux.org ([131.211.28.48]:36037 "EHLO humbolt.nl.linux.org") by vger.kernel.org with ESMTP id ; Sun, 1 Sep 2002 17:25:30 -0400 Content-Type: text/plain; charset=US-ASCII From: Daniel Phillips To: Andrew Morton Subject: Re: [RFC] [PATCH] Include LRU in page count Date: Sun, 1 Sep 2002 23:32:25 +0200 X-Mailer: KMail [version 1.3.2] Cc: Christian Ehrhardt , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org References: <3D644C70.6D100EA5@zip.com.au> <3D712682.66E2D3B2@zip.com.au> In-Reply-To: <3D712682.66E2D3B2@zip.com.au> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Message-Id: <20020901212943Z16578-4014+1360@humbolt.nl.linux.org> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1829 Lines: 39 On Saturday 31 August 2002 22:26, Andrew Morton wrote: > Daniel Phillips wrote: > > > > Manfred suggested an approach to de-racing this race using > > atomic_dec_and_lock, which needs to be compared to the current approach. > > Could simplify things, but not all architectures have an optimised > version. So ia64, mips, parisc and s390 would end up taking > the lru lock on every page_cache_release. I've put some more thought into this and I don't see any real problem with the atomic_dec_and_lock strategy. The only efficiency drawback is the extra locked cmpxchg on every page count dec, and that most likely tips the efficiency advantage ever so slightly in favor of my current strategy. Something else I like about the current strategy is the way the trylock avoids contention - if shrink_cache is active it just leaves the page on the lru for collection later. Sweeping up the orphans is efficient, since the lru lock is batched by shrink_cache. I think I may be even able to make this all work without holding the extra count, but I'll treat that as a background project. The important thing is, the page reaping cycle was never correct before, now it just might be. I'm looking at your spinlock_irq now and thinking the _irq part could possibly be avoided. Can you please remind me of the motivation for this - was it originally intended to address the same race we've been working on here? I can see the advantage of being able to take the lru lock from interrupt context, but we may be able to achieve the intended effect with a trylock. -- Daniel - 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/