Re: kjournald() with DIO

[Andrea Arcangeli <andrea@suse.de>]

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.