From: William Lee Irwin III <wli@holomorphy.com>
To: Andrew Morton <akpm@osdl.org>
Cc: pbadari@us.ibm.com, linux-fsdevel@vger.kernel.org,
ext2-devel@lists.sourceforge.net
Subject: Re: Bufferheads & page-cache reference
Date: Mon, 14 Feb 2005 14:50:33 -0800 [thread overview]
Message-ID: <20050214225033.GY13009@holomorphy.com> (raw)
In-Reply-To: <20050214143142.6c12fdb3.akpm@osdl.org>
On Mon, Feb 14, 2005 at 01:40:58PM -0800, Andrew Morton wrote:
>>> Seems about right. There's also the buffer_heads_over_limit logic in
>>> mm/vmscan.c and fs/buffer.c. That logic has a hole in that it requires
>>> that there be a highmem shortage before we start to reclaim the lowmem
>>> buffer_heads, but it is somewhat helpful.
William Lee Irwin III <wli@holomorphy.com> wrote:
>> It would be beneficial to close the hole in that logic.
On Mon, Feb 14, 2005 at 02:31:42PM -0800, Andrew Morton wrote:
> Really? Who's hurting?
Apart from the fact that buffer_head proliferation has been a perennial
problem, there's little to go on. By and large 2.6.x production usage
is not yet very significant where I can see it, where the "production"
usage is largely more stressful on account of very long durations and
the variety of unusual situations to which the kernel is subjected.
William Lee Irwin III <wli@holomorphy.com> wrote:
>> Do you have any
>> particularly preferred methods in mind?
On Mon, Feb 14, 2005 at 02:31:42PM -0800, Andrew Morton wrote:
> None that are particularly elegant. One approach might be to trigger a
> highmem zone scan when we hit the limit, and to somehow tell that scan to
> only do buffer_head stripping.
This is largely what I expected. I'll cook something up depending on
what conclusion is made from the above response.
-- wli
next prev parent reply other threads:[~2005-02-14 22:50 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-14 19:30 Bufferheads & page-cache reference Badari Pulavarty
2005-02-14 19:31 ` [Ext2-devel] " Sonny Rao
2005-02-14 21:40 ` Andrew Morton
2005-02-14 22:10 ` William Lee Irwin III
2005-02-14 22:31 ` Andrew Morton
2005-02-14 22:50 ` William Lee Irwin III [this message]
2005-02-15 0:22 ` Badari Pulavarty
2005-02-15 2:57 ` Andrew Morton
2005-02-15 16:03 ` Badari Pulavarty
2005-02-15 17:26 ` Andrew Morton
2005-02-15 1:27 ` Badari Pulavarty
2005-02-15 3:05 ` Andrew Morton
2005-02-15 16:46 ` Badari Pulavarty
2005-02-15 17:54 ` Andrew Morton
2005-02-15 18:15 ` Badari Pulavarty
2005-02-15 19:07 ` Nikita Danilov
2005-02-15 19:39 ` Badari Pulavarty
2005-02-15 20:00 ` Andrew Morton
2005-02-16 0:02 ` [RFC] [PATCH] Generic mpage_writepage() support Badari Pulavarty
2005-02-16 11:41 ` Nikita Danilov
2005-02-16 18:37 ` Badari Pulavarty
2005-02-16 19:09 ` Dave Kleikamp
2005-02-16 19:28 ` Badari Pulavarty
2005-02-16 19:43 ` Dave Kleikamp
2005-02-16 21:38 ` [Ext2-devel] " Badari Pulavarty
2005-02-16 21:46 ` Dave Kleikamp
2005-02-17 0:13 ` [RFC] [PATCH] nobh_write_page() support Badari Pulavarty
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=20050214225033.GY13009@holomorphy.com \
--to=wli@holomorphy.com \
--cc=akpm@osdl.org \
--cc=ext2-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=pbadari@us.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).