All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Guennadi Liakhovetski <gl@dsa-ac.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [2.6.17.4] slabinfo.buffer_head increases
Date: Wed, 13 Sep 2006 12:32:41 +1000	[thread overview]
Message-ID: <45076DC9.2090404@yahoo.com.au> (raw)
In-Reply-To: <Pine.LNX.4.63.0609120933450.1700@pcgl.dsa-ac.de>

Guennadi Liakhovetski wrote:
> On Tue, 12 Sep 2006, Nick Piggin wrote:
> 
>> Guennadi Liakhovetski wrote:
>>
>>>> On Mon, 10 Jul 2006, Guennadi Liakhovetski wrote:
>>>>
>>>>> I am obsering a steadily increasing buffer_head value in slabinfo 
>>>>> under
>>>>> 2.6.17.4. I searched the net / archives and didn't find anything
>>>>> directly relevant. Does anyone have an idea or how shall we debug it?
>>>>
>>>>
>>>
>>> The problem is still there under 2.6.18-rc2. I narrowed it down to 
>>> ext3 journal. To reproduce one just has to mount an ext3 partition 
>>> and perform (write) accesses to it. A loop { touch /mnt/foo; sleep 1; 
>>> } suffices - just let it run for a couple of minutes and monitor 
>>> buffer_head in /proc/slabinfo. If you mount it as ext2 the problem is 
>>> gone.
>>
>>
>>
>> What data mode is ext3 mounted with?
> 
> 
> Default, i.e., ordered, I guess.
> 
>> Is the memory reclaimable? If yes, is it a problem?
> 
> 
> Yes, that's why I later wrote that the problem is not real. It was hard 
> to see as we had a lot of free RAM on the system, the system was idle 
> apart from one script that only did "touch x" periodically with the same 
> "x" and the buffer_head slab was growing very steadily. Unlike with ext2 
> / reiserfs. That's why I decided it was not ok. But the memory is 
> reclaimable, so, seems like not a problem. Just a bit odd that such a 
> "harmless" operation causes a steady growth of buffer_heads...

OK. It is just a quirk in the way that ext3 ordered interacts with page freeing
and reclaim, I think. If it is causing you no performance problems then that's
good. Though it is counter intuitive.

Thanks for the report anyway.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

      reply	other threads:[~2006-09-13  2:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-10 11:28 [2.6.17.4] slabinfo.buffer_head increases Guennadi Liakhovetski
2006-07-10 12:19 ` Guennadi Liakhovetski
2006-09-06 11:48   ` Guennadi Liakhovetski
2006-09-12  2:47     ` Nick Piggin
2006-09-12  7:40       ` Guennadi Liakhovetski
2006-09-13  2:32         ` Nick Piggin [this message]

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=45076DC9.2090404@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=gl@dsa-ac.de \
    --cc=linux-kernel@vger.kernel.org \
    /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.