From: "José Luis Domingo López" <jdomingo@internautas.org>
To: linux-kernel@vger.kernel.org
Subject: Re: Suspected bug in shrink_caches()
Date: Thu, 3 Jan 2002 19:46:10 +0100 [thread overview]
Message-ID: <20020103184609.GA3890@localhost> (raw)
In-Reply-To: <200201030538.g035ceM31957@mysql.sashanet.com>
In-Reply-To: <200201030538.g035ceM31957@mysql.sashanet.com>
On Wednesday, 02 January 2002, at 22:38:40 -0700,
Sasha Pachev wrote:
> I am quite sure there is still a bug in shrink_caches(), at least there was
> one in 2.4.17-rc2. I have not tried later releases, but there is nothing in
> the changelog about the fixes anywhere near that area of the code, so I have
> to assume the problem is still there.
> [...]
> When we get to the point where free memory starts running low, even though we
> may have something like 100 MB of cache, shrink_caches() fails to free up
> enough memory, which triggers the evil oom killer. Obviously, in the above
> situation the correct behaviour is to go on cache diet before considering the
> murders.
>
I can confirm this behaviour in my own machine. 128 MB of RAM, swap
space turned off, machine running KDE 2.2.x, Konqueror, rxvt's, gkrellm,
xmms and some daemons, and mighty Mozilla :). At this point there are
still a couple of MB free, a couple buffered and aproximately 40 MB
in caches.
Trying to load OpenOffice641 the kernel feels it's OOM time, and kills
something, usually Mozilla (as it should). However, "watch cat
/proc/meminfo" reports about 30 MB in caches when OOM kicks in. Any
attempt to "tune" parameters under "/proc/sys/vm/" changes nothing.
Attempted changes include:
echo "0 0" > /proc/sys/vm/pagetable_cache
All this is with plain 2.4.17, no patches applied. Another thing I have
observed is caches growing "too" much, but this is more of a subjective
feeling than anything else.
Maybe unrelated, maybe not, is the fact that in 2.4.17 I still see short
"freezes" in interactive response after doing intensive disk access
(untarring something, finishing some dd'ing, rebuilding Debian package
database, etc.). Both on medium-end hardware (128 MB RAM, PIII 600) and
low-end hardware (64 MB RAM, P166). Vanilla 2.4.17 on both, with ext2 as
the only filesystem used in mounted partitions.
--
José Luis Domingo López
Linux Registered User #189436 Debian Linux Woody (P166 64 MB RAM)
jdomingo AT internautas DOT org => Spam at your own risk
next prev parent reply other threads:[~2002-01-03 18:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-03 5:38 Suspected bug in shrink_caches() Sasha Pachev
2002-01-03 18:46 ` José Luis Domingo López [this message]
2002-01-03 21:24 ` Andrew Morton
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=20020103184609.GA3890@localhost \
--to=jdomingo@internautas.org \
--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.