[lkml]   [2005]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: How to diagnose a kernel memory leak

    (Please always do reply-to-all)

    Bruce Guenter <> wrote:
    > On Mon, May 09, 2005 at 10:29:21AM +0200, Alexander Nyberg wrote:
    > > the patch below might help as it works on a lower
    > > level. It accounts for bare pages in the system available
    > > from /proc/page_owner. So a cat /proc/page_owner > tmpfile would be good
    > > when the system starts to go low. There's a sorting program in
    > > Documentation/page_owner.c used to sort the rather large output.
    > I've been running this for a day and a half now, and a few hundred megs
    > of memory is now missing:
    > # free
    > total used free shared buffers cached
    > Mem: 2055648 2001884 53764 0 259024 868484
    > -/+ buffers/cache: 874376 1181272
    > Swap: 1028152 56 1028096
    > I've put the output from the sorting program up at
    > Is this useful information yet, or is there still too much in cached
    > pages to really identify the source?

    It all looks pretty innocent. Please send the contents of /proc/meminfo
    rather than the `free' output. /proc/meminfo has much more info.
    Sometimes /proc/vmstat is also useful.

    If the /proc/meminfo output indicates that there are a lot of slab pages
    then /proc/slabinfo should be looked at.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-05-13 02:22    [W:0.021 / U:0.436 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site