Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933818AbXJRD27 (ORCPT ); Wed, 17 Oct 2007 23:28:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759480AbXJRD2v (ORCPT ); Wed, 17 Oct 2007 23:28:51 -0400 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:60048 "EHLO ebiederm.dsl.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750824AbXJRD2u (ORCPT ); Wed, 17 Oct 2007 23:28:50 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Chris Mason Cc: Christian Borntraeger , Andrew Morton , Nick Piggin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Martin Schwidefsky , "Theodore Ts'o" , stable@kernel.org Subject: Re: [PATCH] rd: Mark ramdisk buffers heads dirty References: <200710151028.34407.borntraeger@de.ibm.com> <200710160956.58061.borntraeger@de.ibm.com> <200710171814.01717.borntraeger@de.ibm.com> <1192648456.15717.7.camel@think.oraclecorp.com> <1192654481.15717.16.camel@think.oraclecorp.com> <1192661889.15717.27.camel@think.oraclecorp.com> <1192665785.15717.34.camel@think.oraclecorp.com> Date: Wed, 17 Oct 2007 21:27:49 -0600 In-Reply-To: <1192665785.15717.34.camel@think.oraclecorp.com> (Chris Mason's message of "Wed, 17 Oct 2007 20:03:05 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) 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: 2166 Lines: 49 Chris Mason writes: > On Wed, 2007-10-17 at 17:28 -0600, Eric W. Biederman wrote: >> Chris Mason writes: >> >> > So, the problem is using the Dirty bit to indicate pinned. You're >> > completely right that our current setup of buffer heads and pages and >> > filesystpem metadata is complex and difficult. >> > >> > But, moving the buffer heads off of the page cache pages isn't going to >> > make it any easier to use dirty as pinned, especially in the face of >> > buffer_head users for file data pages. >> >> Let me specific. Not moving buffer_heads off of page cache pages, >> moving buffer_heads off of the block devices page cache pages. >> >> My problem is the coupling of how block devices are cached and the >> implementation of buffer heads, and by removing that coupling >> we can generally make things better. Currently that coupling >> means silly things like all block devices are cached in low memory. >> Which probably isn't what you want if you actually have a use >> for block devices. >> >> For the ramdisk case in particular what this means is that there >> are no more users that create buffer_head mappings on the block >> device cache so using the dirty bit will be safe. > > Ok, we move the buffer heads off to a different inode, and that indoe > has pages. The pages on the inode still need to get pinned, how does > that pinning happen? > The problem you described where someone cleans a page because the buffer > heads are clean happens already without help from userland. So, keeping > the pages away from userland won't save them from cleaning. > > Sorry if I'm reading your suggestion wrong... Yes. I was suggesting to continue to pin the pages for the page cache pages block device inode, and having the buffer cache live on some other inode. Thus not causing me problems by adding clean buffer_heads to my dirty pages. Eric - 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/