All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Heckmann <heckmann@hbesoftware.com>
To: riel@conectiva.com.br
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: 2.4.8-pre7: still buffer cache problems[+2.4.9-pre3 comments]
Date: Wed, 15 Aug 2001 07:06:22 -0400	[thread overview]
Message-ID: <20010815070622.A27813@hbe.ca> (raw)
In-Reply-To: <Pine.LNX.4.33L.0108091749580.1439-100000@duckman.distro.conectiva> <32779.213.7.62.75.997402832.squirrel@webmail.hbesoftware.com>
In-Reply-To: <32779.213.7.62.75.997402832.squirrel@webmail.hbesoftware.com>; from heckmann@hbesoftware.com on Thu, Aug 09, 2001 at 08:20:32PM -0400

On Thu, Aug 09, 2001 at 08:20:32PM -0400, marc heckmann wrote:
> > 
> > OK, there is no obvious way to do do drop-behind on
> > buffer cache pages, but I think we can use a quick
> > hack to make the system behave well under the presence
> > of large amounts of buffer cache pages.
> > 
> > What we could do is, in refill_inactive_scan(), just
> > moving buffer cache pages to the inactive list regardless
> > of page aging when there are too many buffercache pages
> > around in the system.
> > 
> > Does the patch below help you ?
> 
> well, the buffer cache still got huge and the system still swapped out like
> mad, but it seemed like the buffer cache grew _slower_ and that the vm was
> more fair towards other vm users. so interactivity was better but still far
> from 2.2. and then it oops'ed [I don't think it was because of your patch
> though..]:
> 

I tried 2.4.8 final and it fixes the problem.... could it be the 
fs/buffer.c changes? behaviour is now like 2.2 (good in this case). if I 
have time I'll try 2.4.8-ac5 to se if it also fixes it. thanks to whoever 
is responsible for the fix.

also I tried 2.4.9-pre3 and it performs _much_ [I'd say 10 times better!]
better under high VM load specifically when filling all ram+swap. Where
2.4.8 used to thrash without making any progress what so ever [I'd have to
reset], 2.4.9-pre3 will either oom_kill (the _right_ process) or manage to
handle swap to let processes run without thrashing. this is all on PPC 
without any highmem (192Mb + 200mb swap.).


	Cheers,

	-marc


WARNING: multiple messages have this Message-ID (diff)
From: Marc Heckmann <heckmann@hbesoftware.com>
To: riel@conectiva.com.br
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: 2.4.8-pre7: still buffer cache problems[+2.4.9-pre3 comments]
Date: Wed, 15 Aug 2001 07:06:22 -0400	[thread overview]
Message-ID: <20010815070622.A27813@hbe.ca> (raw)
In-Reply-To: <32779.213.7.62.75.997402832.squirrel@webmail.hbesoftware.com>; from heckmann@hbesoftware.com on Thu, Aug 09, 2001 at 08:20:32PM -0400

On Thu, Aug 09, 2001 at 08:20:32PM -0400, marc heckmann wrote:
> > 
> > OK, there is no obvious way to do do drop-behind on
> > buffer cache pages, but I think we can use a quick
> > hack to make the system behave well under the presence
> > of large amounts of buffer cache pages.
> > 
> > What we could do is, in refill_inactive_scan(), just
> > moving buffer cache pages to the inactive list regardless
> > of page aging when there are too many buffercache pages
> > around in the system.
> > 
> > Does the patch below help you ?
> 
> well, the buffer cache still got huge and the system still swapped out like
> mad, but it seemed like the buffer cache grew _slower_ and that the vm was
> more fair towards other vm users. so interactivity was better but still far
> from 2.2. and then it oops'ed [I don't think it was because of your patch
> though..]:
> 

I tried 2.4.8 final and it fixes the problem.... could it be the 
fs/buffer.c changes? behaviour is now like 2.2 (good in this case). if I 
have time I'll try 2.4.8-ac5 to se if it also fixes it. thanks to whoever 
is responsible for the fix.

also I tried 2.4.9-pre3 and it performs _much_ [I'd say 10 times better!]
better under high VM load specifically when filling all ram+swap. Where
2.4.8 used to thrash without making any progress what so ever [I'd have to
reset], 2.4.9-pre3 will either oom_kill (the _right_ process) or manage to
handle swap to let processes run without thrashing. this is all on PPC 
without any highmem (192Mb + 200mb swap.).


	Cheers,

	-marc

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

  reply	other threads:[~2001-08-15 11:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-09 13:56 2.4.8-pre7: still buffer cache problems marc heckmann
2001-08-09 13:56 ` marc heckmann
2001-08-09 16:09 ` Chris Mason
2001-08-09 16:09   ` Chris Mason
2001-08-09 20:55 ` Rik van Riel
2001-08-09 20:55   ` Rik van Riel
2001-08-10  0:20   ` marc heckmann
2001-08-10  0:20     ` marc heckmann
2001-08-15 11:06     ` Marc Heckmann [this message]
2001-08-15 11:06       ` 2.4.8-pre7: still buffer cache problems[+2.4.9-pre3 comments] Marc Heckmann
2001-08-10  1:52   ` 2.4.8-pre7: still buffer cache problems Ed Tomlinson
2001-08-10  1:52     ` Ed Tomlinson
2001-08-10  8:01   ` Zdenek Kabelac

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=20010815070622.A27813@hbe.ca \
    --to=heckmann@hbesoftware.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=riel@conectiva.com.br \
    /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.