From: space-00002@vortex.physik.uni-konstanz.de
To: linux-kernel@vger.kernel.org
Subject: buffer/memory strangeness in 2.4.16
Date: Thu, 29 Nov 2001 21:39:16 +0100 [thread overview]
Message-ID: <200111292030.fATKU1s05921@vortex.physik.uni-konstanz.de> (raw)
In-Reply-To: <200111291201.fATC1pd04206@lists.us.dell.com>
In-Reply-To: <200111291201.fATC1pd04206@lists.us.dell.com>
Hi,
I am experiencing a bit of strange system behaviour in a vanilla 2.4.16
kernel (2.95.3, very stable machine etc.)
I noticed, that after running for a while (day) I had significantly less
memory available for my simulation program than right after booting. Looking
at the problem using 'xosview' (or 'free'), I noticed that there was a large
number of MBs filled with 'buffers' that did not get wiped when other
programs need the memory. The system seems to rather kill an 'offender' than
clean out buffers.
Right after booting, I can allocate about 650MBs memory using the little
program attached below. After a day (or after running updatedb), under the
same conditions, even in single user mode with only a shell running (!) this
is not possible anymore and the program (below), trying to allocate only
300-400MBs, gets killed by the system after making it unresponsive for many
seconds.
Apparently this problem occurs after running 'updatedb', which fills 'free
memory' and generates lots of filled cache and buffers on my system.
This sort of behaviour must have been introduced after 2.4.13, which does not
show these problems.
Please tell me if somebody needs more information to debug this, or if this
behaviour is normal or expected. Please cc: me as I am only on lkml-digest.
Cheers
Jan
P.S. All RAM slots are full, so please don't suggest buying more memory as a
solution :^)
-------------------%<-----------------------
#include <stdio.h>
#define ONE_MEG 1024 * 1024
main ()
{
long mem_avail = ONE_MEG;
char *buf;
char userchar = '@';
int howmany;
while (1)
{
printf ("Number of MBs to allocate? ");
scanf ("%d", &howmany);
printf ("Trying to allocate %ld bytes: ", mem_avail*howmany);
getchar ();
if ((buf = (char *) malloc ((size_t) mem_avail*howmany))){
printf (" success!\n");
printf ("Now filling it up...\n");
memset (buf, userchar, mem_avail * howmany);
printf ("Hit ENTER to free the memory.\n");
getchar ();
free (buf);
} else {
printf (" failed :(\n");
}
}
}
-------------------%<-----------------------
next parent reply other threads:[~2001-11-29 20:31 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 ` space-00002 [this message]
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
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=200111292030.fATKU1s05921@vortex.physik.uni-konstanz.de \
--to=space-00002@vortex.physik.uni-konstanz.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 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®