Memory leak

Memory leak

[Skip Gaede]

Folks,


I'm looking for a recipe on how to track where my memory is
disappearing to. I am running kernel 2.4.19-pre10-ben0,
patched for the nubus-pmac platform. I have 40 MB RAM and a
100 MB swap file on the local hard disk.


I am using the MkLinux booter and the kernel with an initrd.
During the first init, I get an IP address and the path to
the NFS root. I then do a pivot-root, and run the XFree86
Server -query 192.168.0.1, where I do an autologon, and
start up KDE 3.0.1 and Mozilla 1.0 running Choffman's
browser buster. I also am running the snmp daemon, so I can
monitor memory use from my server with a perl script.


When first booted, the kernel takes about 16 MB of memory,
and after starting the X server, I have about 2000k
available physical memory, and no swap file usage. Over
the next 7 hours, I eat up about 20 MB of swap file, and at
some point the available physical memory drops down to
about 150k for about an hour and then the system locks up.
During the same period of time, I can monitor memory use on
the client on another console, and the amount of memory
allocated to each process remains fairly stable up until
lockup.


I'd like to understand what's going on. Can someone suggest
what data I ought to be collecting, or perhaps some
parameters I can tweak to modify the behavior?


Thanks,
Skip


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Memory leak

[diekema_jon]

> I'm looking for a recipe on how to track where my memory is
> disappearing to. I am running kernel 2.4.19-pre10-ben0,
> patched for the nubus-pmac platform. I have 40 MB RAM and a
> 100 MB swap file on the local hard disk.

I have a similar problem, and I have to back down to Linux 2.4.4.
Linux 2.4.8 and newer had a problem, but 2.4.4 was ok.  Somewhere
between 2.4.4 and 2.4.8 the problem appeared.  If you want more
details as to what versions after 2.4.8 that had problem I can supply
that tonight.

2.4.4 ok
2.4.8 memory leak

Our application uses a socket based network connection, and this
network activity tickled the memory leak problem.  We can run top,
and see the amount of free memory keep dropping.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Memory leak

[Skip Gaede]

On Thursday 20 June 2002 03:52, Skip Gaede wrote:
> Folks,
>
>
> I'm looking for a recipe on how to track where my memory
> is disappearing to. I am running kernel
> 2.4.19-pre10-ben0, patched for the nubus-pmac platform. I
> have 40 MB RAM and a 100 MB swap file on the local hard
> disk.
>
OK, I recompiled the kernel with CONFIG_DEBUG_SLAB. The
memory is being consumed by the size-2048 cache, which I
believe is being used for network traffic.

I have two scenarios:

1) boot the system off the local hard drive and run X -query
192.168.0.1

2) boot the kernel+initrd off the local hard drive and mount
root via NFS, then run X -query ...

In the first case, the 2048 cache works well. After 30
minutes of continuous network traffic,

size-2048      5   50  2048    3    25  1

In the second case, after only 15 minutes

size-2048   187 228  2048  94  114  1  (15 min)
size-2048   918 928  2048 460 464  1  (60 min)

So the number of active buffers is much higher and it
continues to grow. Does anyone have any idea as to why this
is happening, or how to debug it?

Thanks,
Skip

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Memory Leak

[Aman]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

 Hi All
 I am using consistent_alloc () to allocate consistent memory for DMA.  When
I free the buffers using consistent_free(), the /proc/meminfo shows a
memory leak of the buffer size allocated.

 I have attached a  module code to allocate memory when inserted and free
 when removed. The memory leak can be found using the command cat
/proc/meminfo.

 Also the consistent_alloc call gives an error something like "Kernel bug at
cachemap.." if we try to allocate more than 2MB.

Can anyone help me in solving these issues

Thanking you in advance
Regards
Aman




[-- Attachment #2: alloc_test.c --]
[-- Type: application/octet-stream, Size: 983 bytes --]

#define __NO_VERSION__
#include <linux/module.h>
#include <linux/version.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/fs.h>
#include <linux/slab.h>
#include <linux/sched.h>
#include <linux/ioctl.h>
#include <linux/proc_fs.h>
#include <linux/wrapper.h>
#include <asm/io.h>


typedef int sint32_t;

char kernel_version[]= UTS_RELEASE;

uint8_t        *pu8_buffer;

int init_module (void)
{
    dma_addr_t      str_phys_addr;

    printk ("Init module\n");

    pu8_buffer = consistent_alloc (GFP_KERNEL, 0x200000, &str_phys_addr);

    if (pu8_buffer == NULL)
    {
        printk ("Could not allocate memory\n");

        return 0;
    }

    printk ("Physical address = 0x%x\n", str_phys_addr);
    printk ("Virtual address = 0x%x\n", (uint32_t) pu8_buffer);

    return 0;
}

void cleanup_module (void)
{
    printk ("Freeing )x%x\n", (uint32_t) pu8_buffer);

    consistent_free (pu8_buffer);

    return;
}

Re: Memory Leak

[Matt Porter]

On Thu, Mar 13, 2003 at 01:20:25AM +0530, Aman wrote:
>  Hi All
>  I am using consistent_alloc () to allocate consistent memory for DMA.  When
> I free the buffers using consistent_free(), the /proc/meminfo shows a
> memory leak of the buffer size allocated.
>
>  I have attached a  module code to allocate memory when inserted and free
>  when removed. The memory leak can be found using the command cat
> /proc/meminfo.

This was fixed three months ago in the development trees.

>  Also the consistent_alloc call gives an error something like "Kernel bug at
> cachemap.." if we try to allocate more than 2MB.

Of course, MAX_ORDER is 10 (in 2.4) and consistent_alloc() is based on
__get_free_pages().

I suggest reading "Understanding the Linux Kernel", "Linux Device
Drivers", and Documentation/* as a starting point for kernel
development.

If you simply must have more consistent memory then you can use
mem= on the command line to reduce the memory available to the
kernel and then use __ioremap/consistent_sync to map the massive
buffer and make it consistent.

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/