Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 6 Feb 2001 15:56:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 6 Feb 2001 15:56:03 -0500 Received: from perninha.conectiva.com.br ([200.250.58.156]:35598 "EHLO perninha.conectiva.com.br") by vger.kernel.org with ESMTP id ; Tue, 6 Feb 2001 15:55:43 -0500 Date: Tue, 6 Feb 2001 17:05:31 -0200 (BRST) From: Marcelo Tosatti To: Ingo Molnar cc: Christoph Hellwig , Linus Torvalds , Ben LaHaise , "Stephen C. Tweedie" , Alan Cox , Manfred Spraul , Steve Lord , Linux Kernel List , kiobuf-io-devel@lists.sourceforge.net, Ingo Molnar Subject: Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait 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 On Tue, 6 Feb 2001, Ingo Molnar wrote: > > On Tue, 6 Feb 2001, Christoph Hellwig wrote: > > > The second is that bh's are two things: > > > > - a cacheing object > > - an io buffer > > > > This is not really an clean appropeach, and I would really like to get > > away from it. > > caching bmap() blocks was a recent addition around 2.3.20, and i suggested > some time ago to cache pagecache blocks via explicit entries in struct > page. That would be one solution - but it creates overhead. Think about a given number of pages which are physically contiguous on disk -- you dont need to cache the block number for each page, you just need to cache the physical block number of the first page of the "cluster". SGI's pagebuf do that, and it would be great if we had something similar in 2.5. It allows us to have fast IO clustering. > but there isnt anything wrong with having the bhs around to cache blocks - > think of it as a 'cached and recycled IO buffer entry, with the block > information cached'. Usually we need to cache only block information (for clustering), and not all the other stuff which buffer_head holds. > frankly, my quick (and limited) hack to abuse bhs to cache blocks just > cannot be a reason to replace bhs ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/