Messages in this thread |  | | | Date | Mon, 24 Jan 2005 21:47:00 +0100 | | From | Jens Axboe <> | | Subject | Re: Memory leak in 2.6.11-rc1? |
| |
On Mon, Jan 24 2005, Alexander Nyberg wrote: > > I don't think I've ever really seen code to diagnose this. > > > > A simplistic approach would be to add eight or so ulongs into struct page, > > populate them with builtin_return_address(0...7) at allocation time, then > > modify sysrq-m to walk mem_map[] printing it all out for pages which have > > page_count() > 0. That'd find the culprit. > > Hi Andrew > > I put something similar together of what you described but I made it a > proc-file. It lists all pages owned by some caller and keeps a backtrace > of max 8 addresses. Each page has an order, -1 for unused and if used it lists > the order under which the first page is allocated, the rest in the group are kept -1. > Below is also a program to sort the enormous amount of > output, it will group together backtraces that are alike and list them like: > > 5 times: Page allocated via order 0 > [0xffffffff8015861f] __get_free_pages+31 > [0xffffffff8015c0ef] cache_alloc_refill+719 > [0xffffffff8015bd74] kmem_cache_alloc+84 > [0xffffffff8015bddc] alloc_arraycache+60 > [0xffffffff8015d15d] do_tune_cpucache+93 > [0xffffffff8015bbf8] cache_alloc_debugcheck_after+280 > [0xffffffff8015d31d] enable_cpucache+93 > [0xffffffff8015d8a5] kmem_cache_create+1365
Here is the output of your program (somewhat modified, I cut the runtime by 19/20 killing the 1-byte reads :-) after 10 hours of use with bk-current as of this morning.
-- Jens Axboe
[unhandled content-type:application/x-bunzip2] |  |