From: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-ext4@vger.kernel.org, sct@redhat.com,
linux-fsdevel@vger.kernel.org
Subject: Re: [RFC][PATCH] JBD: release checkpoint journal heads through try_to_release_page when the memory is exhausted
Date: Tue, 28 Oct 2008 11:46:27 +0900 [thread overview]
Message-ID: <49067D03.6080609@jp.fujitsu.com> (raw)
In-Reply-To: <20081027142657.2120aa3f.akpm@linux-foundation.org>
Hi Andrew.
Thank you for your useful comment.
Andrew Morton wrote:
> (added linux-fsdevel)
>
> On Thu, 23 Oct 2008 17:41:01 +0900
> Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com> wrote:
<SNIP>
> > I managed to build a shrinker callback function for the journal_head slab cache.
> > > This code size is less than before but the logic of it seems to be more complex
> > > than before.
> > > However, I haven't got any troubles while I am testing some easy load operations
> > > on the fixed kernel.
> > > But I think a system may hang up if concurrently several journal_head shrinker
> > > are executed.
> > > So, I will retry to build more appropriate fix.
>
> yeah, that's not very pretty either, is it?
Yes...
I realized fixing only within buffer_head or jbd needs a more complex code.
> > > Please give me comments if you have a nicer idea.
> Stepping back a bit...
>
> The basic problem is, I believe, that some client of the blockdev
> (ext3) is adding metadata to the blockdev's data structures
> (buffer_heads) but we have no means by which the blockdev code can call
> back into that client requesting that the metadata be released, yes?
Yes.
> We can fix the problem which you've identified by adding a means for
> the blockdev code (def_blk_aops.releasepage()) to call back into ext3,
> yes?
Yes.
At first, I tried to fix by using only filesystem approach.
- ver.1: fixing in buffer_head
- ver.2: adding shrinker of journal_head (for releasing buffer_head)
But these approaches become complex code.
So, we should fix the essence of the problem.
> If so, how do we do that?
>
> I seem to recall that there's code somewhere in the tree which does
> things like taking a copy of bdev->address_space_operations and
> reinstalling that, and overwriting selected fields, and then arranging
> somehow for the old value to be reinstalled when the client releases
> the blockdev. That's plain nasty.
uh-huh.
I try to fix this problem again by using your approach,
blkdev_register_releasepage/blkdev_unregister_releasepage().
Best Regards,
Toshiyuki Okajima
next prev parent reply other threads:[~2008-10-28 2:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-17 13:37 [RFC][PATCH] JBD: release checkpoint journal heads through try_to_release_page when the memory is exhausted Toshiyuki Okajima
2008-10-20 23:02 ` Andrew Morton
2008-10-21 2:49 ` Toshiyuki Okajima
2008-10-23 8:41 ` Toshiyuki Okajima
2008-10-27 21:26 ` Andrew Morton
2008-10-28 2:46 ` Toshiyuki Okajima [this message]
2008-11-05 4:11 ` [PATCH][BUG] jbd: fix the root cause of "no transactions" error in __log_wait_for_space() Toshiyuki Okajima
2008-11-05 13:53 ` Theodore Tso
2008-11-05 14:05 ` [PATCH] jbd: don't give up looking for space so easily in __log_wait_for_space Theodore Ts'o
2008-11-05 14:05 ` [PATCH] jbd2: don't give up looking for space so easily in __jbd2_log_wait_for_space Theodore Ts'o
2008-11-07 3:17 ` [PATCH][BUG] jbd: fix the root cause of "no transactions" error in __log_wait_for_space() Toshiyuki Okajima
2008-11-12 7:49 ` [PATCH 0/3][RFC] release block-device-mapping buffer_heads which have the filesystem private data for avoiding oom-killer Toshiyuki Okajima
2008-11-12 7:51 ` [PATCH 1/3][RFC] vfs: " Toshiyuki Okajima
2008-11-12 7:53 ` [PATCH 2/3][RFC] ext3: " Toshiyuki Okajima
2008-11-12 7:55 ` [PATCH 3/3][RFC] ext4: " Toshiyuki Okajima
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49067D03.6080609@jp.fujitsu.com \
--to=toshi.okajima@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=sct@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.