From: Stephan von Krawczynski <skraw@ithnet.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: mcelrath@draal.physics.wisc.edu, linux-kernel@vger.kernel.org
Subject: Re: "Cached" grows and grows and grows...
Date: Sun, 9 Sep 2001 15:15:09 +0200 [thread overview]
Message-ID: <20010909151509.6a0c7d68.skraw@ithnet.com> (raw)
In-Reply-To: <E15flgs-0004BN-00@the-village.bc.nu>
In-Reply-To: <20010908184758.696bb9d1.skraw@ithnet.com> <E15flgs-0004BN-00@the-village.bc.nu>
On Sat, 8 Sep 2001 18:14:46 +0100 (BST) Alan Cox <alan@lxorguk.ukuu.org.uk>
wrote:
> > // printk(KERN_ERR "__alloc_pages: %lu-order allocation failed.\n",
order)
> > return NULL;
> >
> > If there is no printk, you will obviously not notice the problem. You can
bet
> > your car on not "seeing the problem".
>
> That printk is commented out because its pointless and bogus noise. It just
> causes confused bug reporting. The stuff that matters is cache sizes
> shrinking back when we need memory not slowly eating the computer alive.
Hm, I guess I had to find out, that you've the same problem than linus' tree,
only on "the other side of the street". This is a meminfo from a 2.4.9-ac9
kernel working one day, and then going crazy on too low mem. "Going crazy" here
means that kswapd took virtually over the cpu(s) and swapped the hell out the
machine:
(BTW you can see that swap did not really grow, but seems to get in and out
permanently)
total: used: free: shared: buffers: cached:
Mem: 921706496 894324736 27381760 4096 783917056 29102080
Swap: 271392768 13185024 258207744
MemTotal: 900104 kB
MemFree: 26740 kB
MemShared: 4 kB
Buffers: 765544 kB
Cached: 15744 kB
SwapCached: 12676 kB
Active: 502132 kB
Inact_dirty: 291836 kB
Inact_clean: 0 kB
Inact_target: 80 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 900104 kB
LowFree: 26740 kB
SwapTotal: 265032 kB
SwapFree: 252156 kB
You are right: page cache shrunk.
You are wrong: it does _not_ work, because now buffers increased and obviously
cannot be shrunk to allow "normal" applications to run. I could not even
shutdown the machine correctly. It looks like a deadlock in vm to me.
I switched back to Linus' tree, because it does have problems, but is not dead
within one day.
Regards,
Stephan
next prev parent reply other threads:[~2001-09-09 13:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-07 16:08 "Cached" grows and grows and grows Bob McElrath
2001-09-07 17:13 ` Stephan von Krawczynski
2001-09-07 22:15 ` Alan Cox
2001-09-07 22:24 ` Bob McElrath
2001-09-08 0:53 ` VM improvement in -ac [was: "Cached" grows and grows and grows...] Mike Fedyk
2001-09-08 16:47 ` "Cached" grows and grows and grows Stephan von Krawczynski
2001-09-08 17:14 ` Alan Cox
2001-09-09 13:15 ` Stephan von Krawczynski [this message]
2001-09-09 13:34 ` Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2001-09-26 1:55 M. Edward Borasky
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=20010909151509.6a0c7d68.skraw@ithnet.com \
--to=skraw@ithnet.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=mcelrath@draal.physics.wisc.edu \
/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