linux-ext4 - Re: [RFC][PATCH] JBD: release checkpoint journal heads through try_to_release

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48FD432B.80006@jp.fujitsu.com>
Date:	Tue, 21 Oct 2008 11:49:15 +0900
From:	Toshiyuki Okajima <toshi.okajima@...fujitsu.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	linux-ext4@...r.kernel.org, sct@...hat.com
Subject: Re: [RFC][PATCH] JBD: release checkpoint journal heads through try_to_release_page
 when the memory is exhausted

Hi Andrew.
Thank you for your comment.

Andrew Morton wrote:
> On Fri, 17 Oct 2008 22:37:16 +0900 (JST)
> Toshiyuki Okajima <toshi.okajima@...fujitsu.com> wrote:
> 
>> Hi.
>>
>> I found the situation where OOM-Killer happens easily.
>> I will inform you of it. 
>> I tried to fix this problem to make OOM-Killer not happen easily as much as 
>> possible.
<SNIP>
> OK.
> 
>> ---
>>  fs/buffer.c                 |   23 ++++++++++++++++++++++-
>>  fs/jbd/journal.c            |    7 +++++++
>>  fs/jbd/transaction.c        |   39 +++++++++++++++++++++++++++++++++++++++
>>  include/linux/buffer_head.h |    7 +++++++
>>  include/linux/jbd.h         |    1 +
>>  5 files changed, 76 insertions(+), 1 deletion(-) 
> 
> The patch is fairly complex, and increasing the buffer_head size can be
Yes.
Applying this fix causes the buffer_head size to increase.
The increase of the buffer_head size changes into 60 bytes from 56 bytes
on x86 system.
As a result, the maximum number of buffer heads of one slab changes
into 63 from 64.
(The increase of the size is less than 2%.)
Therefore I think this change influences system performance hardly.
And I rather want to add a new member because I think it is useful for
not only this fix but also the future.

> rather costly.  An alternative might be to implement a shrinker
> callback function for the journal_head slab cache.  Did you consider
> this?
Yes.
But the unused-list and counters are required by managing the shrink targets
("journal head") if we implement a shrinker.
I thought that comparatively big code changes were necessary for jbd
to accomplish it.

However I will try it.

Best Regards,
Toshiyuki Okajima

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html