From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrea Arcangeli Subject: Re: kjournald() with DIO Date: Thu, 15 Sep 2005 22:20:19 +0200 Message-ID: <20050915202019.GK4122@opteron.random> References: <20050912172935.19907edf.akpm@osdl.org> <1126630370.14837.60.camel@dyn9047017102.beaverton.ibm.com> <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> 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]:11058 "EHLO opteron.random") by vger.kernel.org with ESMTP id S1161008AbVIOUUN (ORCPT ); Thu, 15 Sep 2005 16:20:13 -0400 To: Andrew Morton Content-Disposition: inline In-Reply-To: <20050915130018.287270e4.akpm@osdl.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Sep 15, 2005 at 01:00:18PM -0700, Andrew Morton wrote: > Memory reclaim will reclaim dirty pages ;) ;) > Probably we could simulate ->releasepage(page) by using > ->invalidatepage(page, PAGE_CACHE_SIZE), but that's relying on > side-effects, or would need new semantics defined, or something. The problem is that one thing is the memory reclaim, one thing is the invalidate_inode_pages and one thing is the truncate. They need three different behaviours. But we've only two API to ask the fs to get rid of the buffers, one is destroying dirty buffers, the other is non-blocking, we might need one that is blocking and it isn't destroying dirty buffers. The "wait/gfpmask" parameter to releasepage is ignored by ext3, perhaps we should change the semantics of that bit, and have it passed as GFP_KERNEL only by the invalidate_inode_pages. > I made releasepage() nonblocking to avoid blocking processes in the memory > reclaim paths. Given that it's best-effort, it may as well just trylock > everything it needs and give up if that doesn't work out. I agree the memory reclaim can remain nonblocking. However note that the failure here is in try_to_free_buffers because the buffer is pinned by the journal code (it's not a trylock failing). Buffer is BH_Mapped, BH_Req, BH_Uptodate (0x19) - nicely tracked by IBM. > I think ->releasepage() was being called under locks at some stage but that > appears to no longer be the case. I'm a bit worried about the i_sem if waiting in releasepage but there should be no other locks in the way. We need the blocking behaviour only for invalidate_inode_pages.