From: space-00002@vortex.physik.uni-konstanz.de
To: akpm@zip.com.au, riel@imladris.surriel.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: buffer/memory strangeness in 2.4.16 / 2.4.17pre2
Date: Sun, 2 Dec 2001 18:08:16 +0100 [thread overview]
Message-ID: <200112021709.fB2H9ws14663@vortex.physik.uni-konstanz.de> (raw)
In-Reply-To: <Pine.LNX.4.33L.0112021014330.4079-100000@imladris.surriel.com>
In-Reply-To: <Pine.LNX.4.33L.0112021014330.4079-100000@imladris.surriel.com>
I verified this by throwing in 1GB of swap. It does lose the buffers
eventually, but it does so under great pains. However, since I do have
*plenty* memory and slow disks, I prefer running without swap. These settings
appear to be broken (2.4.13 worked!).
Without swap, I would have to reboot every day to make my simulation happy.-
But it needs to allocate and use *only* about 300 of 768MB which *should* be
available, only because the night before a cron job kicked off 'updatdb'
filling the buffers.
Without swap, it really is *this* bad in 2.4.16 and the latest pre-releases.
RAM is full of buffers that just won't disappear to make room for more
important stuff. My simulation gets killed *every time* until I reboot to
free 'buffers' or add swap. (This makes everything slower in total.)
:-(
Jan
On Sunday 02 December 2001 13:17, Rik wrote:
> On Sat, 1 Dec 2001, Andrew Morton wrote:
> > You'll find that if you push the machine really hard - allocate
> > 1.5x physical memory and touch it all then the VM will, eventually,
> > with great reluctance and much swapping, relinquish the 30 megabytes
> > of buffercache memory. But it's out of whack.
>
> This is an expected (and very bad) side effect of use-once.
>
> > If we put anon pages on the active list instead, then shrink_caches()
> > and refill_inactive() start to do something, and they move that stale
> > old buffercache memory onto the inactive list where it can be freed.
>
> This would fix the problem of not being able to evict stale
> active pages, but I have no idea if it would unbalance
> something else.
>
> > This is just a random hack. I don't understand what's going on in
> > the VM, let alone what's *supposed* to be going on. And given the
> > state of documentation available to us, I never will.
>
> The balancing in Andrea's VM is just too subtle to understand
> without docs, that is, if there is any particular idea behind
> it and it isn't just experimentation.
>
> regards,
>
> Rik
next prev parent reply other threads:[~2001-12-02 17:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200111291201.fATC1pd04206@lists.us.dell.com>
2001-11-29 20:39 ` buffer/memory strangeness in 2.4.16 space-00002
2001-11-30 9:29 ` Andrew Morton
2001-12-01 22:07 ` buffer/memory strangeness in 2.4.16 / 2.4.17pre2 space-00002
2001-12-02 4:43 ` Andrew Morton
2001-12-02 12:17 ` Rik van Riel
2001-12-02 17:08 ` space-00002 [this message]
2001-12-14 1:30 ` buffer/memory strangeness in 2.4.16; fixed in 2.4.17-rc1 space-00002
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=200112021709.fB2H9ws14663@vortex.physik.uni-konstanz.de \
--to=space-00002@vortex.physik.uni-konstanz.de \
--cc=akpm@zip.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@imladris.surriel.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
all inboxes | Powered by JetHome®