From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrea Arcangeli Subject: Re: kjournald() with DIO Date: Thu, 15 Sep 2005 23:03:58 +0200 Message-ID: <20050915210358.GL4122@opteron.random> References: <20050913160701.355cd46a.akpm@osdl.org> <1126718583.4010.6.camel@localhost.localdomain> <20050914111809.41c5b395.akpm@osdl.org> <1126734025.4010.21.camel@localhost.localdomain> <20050914150224.3b6d7051.akpm@osdl.org> <1126796604.14837.111.camel@dyn9047017102.beaverton.ibm.com> <20050915192225.GJ4122@opteron.random> <20050915130018.287270e4.akpm@osdl.org> <20050915202019.GK4122@opteron.random> <20050915133500.754a8b4d.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pbadari@us.ibm.com, cmm@us.ibm.com, linux-fsdevel@vger.kernel.org, sct@redhat.com Return-path: Received: from ppp-217-133-42-200.cust-adsl.tiscali.it ([217.133.42.200]:58439 "EHLO opteron.random") by vger.kernel.org with ESMTP id S1161026AbVIOVD5 (ORCPT ); Thu, 15 Sep 2005 17:03:57 -0400 To: Andrew Morton Content-Disposition: inline In-Reply-To: <20050915133500.754a8b4d.akpm@osdl.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Sep 15, 2005 at 01:35:00PM -0700, Andrew Morton wrote: > I'll need reminding - why was the buffer unfreeable? Because kjournald had > a ref on it? Whereabouts is that happening? Yes, kjournald had a ref (b_count) on it. It's happening when running iozone in some way (Badari knows how to reproduce). I was now wondering why it's a problem to destroy dirty buffers in invalidate_inode_pages2? (ok, ignoring the detail that PageDirty may return true inside invalidate_complete_page) Clearly we can't do that inside releasepage, but invalidate_inode_pages2 is all about destroying the dirty and uptodate information, since we just finished writing with direct-io (or at least the dirty info isn't that important anymore, we're still in our write context for those pages that we're invalidating [even better with the range]). If we could just have a blocking version of try_to_release_page I guess that would be better, but even the ->invalidatepage behaviour may not be that bad for invalidate_inode_pages2. Or am I missing something?