mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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");
                }
        }
}

-------------------%<-----------------------

       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®