Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261766AbTIXEOm (ORCPT ); Wed, 24 Sep 2003 00:14:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261772AbTIXEOm (ORCPT ); Wed, 24 Sep 2003 00:14:42 -0400 Received: from nat-pool-bos.redhat.com ([66.187.230.200]:31765 "EHLO chimarrao.boston.redhat.com") by vger.kernel.org with ESMTP id S261766AbTIXEOi (ORCPT ); Wed, 24 Sep 2003 00:14:38 -0400 Date: Wed, 24 Sep 2003 00:12:51 -0400 (EDT) From: Rik van Riel X-X-Sender: riel@chimarrao.boston.redhat.com To: Linus Torvalds cc: Larry McVoy , Andrea Arcangeli , , Kernel Mailing List , Matthew Wilcox , Marcelo Tosatti Subject: Re: log-buf-len dynamic 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: 1570 Lines: 39 On Tue, 23 Sep 2003, Linus Torvalds wrote: > Yeah, SunOS was nice. But I really think it's the access patterns that > changed. Absolutely. Garbage collection and object orientation have obsoleted LRU and related algorithms. Huge memory sizes also have done their share to obsolete recency based replacement algorithms. I suspect we'll want something closer to a frequency based replacement scheme in the future. Possibly something like LIRS or ARC, but adapted to work in a general purpose OS in a very light weight way. The argument that because we have more memory replacement is no longer as important doesn't quite hold because the cost of page replacement, measured in cpu cycles, has gone completely through the roof in the last decades. Then there's the whole different bag of cookies that is the caching of filesystem metadata, like our inode and dentry caches. I'm not sure what would be a good replacement strategy for those, but I do know that we'll want a good algorithm here because hard disks (and the number of files on them) are growing so much faster than anything else in our computers... -- "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/