On Fri, Feb 18, 2011 at 10:14 PM, Steve Chen <[email protected]> wrote:

> On Fri, Feb 18, 2011 at 4:44 AM, Yinglin Luan <[email protected]> wrote:
> > Hi, everyone
> >
> > I notice that the amount of free memory on my dm365 evm gets smaller and
> > smaller, so I enable CONFIG_DEBUG_KMEMLEAK in "Kernel hacking".When I do
> > 'cat /sys/kernel/debug/kmemleak', I get an output:
> >
> > unreferenced object 0xc12920c0 (size 192):
> >   comm "softirq", pid 0, jiffies 126399
> >   hex dump (first 32 bytes):
> >     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> >     00 00 00 00 00 00 00 00 00 20 a4 c2 00 00 00 00  ......... ......
> >   backtrace:
> >     [<c00ab5d8>] __save_stack_trace+0x34/0x40
> >     [<c00ab6e8>] create_object+0x104/0x1fc
> >     [<c0326a90>] kmemleak_alloc+0x40/0x84
> >     [<c00a891c>] kmem_cache_alloc+0xf4/0x10c
> >     [<c028b028>] __alloc_skb+0x34/0x108
> >     [<c028bc7c>] dev_alloc_skb+0x20/0x44
> >     [<c02035e4>] emac_net_alloc_rx_buf+0x24/0xa8
> >     [<c02047e8>] emac_poll+0x244/0x5d0
> >     [<c0292af4>] net_rx_action+0xb4/0x274
> >     [<c004f648>] __do_softirq+0xb0/0x164
> >     [<c004f75c>] irq_exit+0x60/0xb8
> >     [<c0035074>] asm_do_IRQ+0x74/0x8c
> >     [<c0035ad8>] __irq_svc+0x58/0xa4
> >     [<c0036fac>] cpu_idle+0x80/0xf0
> >     [<c0326478>] rest_init+0x70/0x84
> >     [<c00089dc>] start_kernel+0x28c/0x2e4
> > unreferenced object 0xc2c34000 (size 2048):
> >   comm "softirq", pid 0, jiffies 126399
> >   hex dump (first 32 bytes):
> >     00 00 00 00 4c 37 f5 2b 6a 6a 19 63 98 82 08 00  ....L7.+jj.c....
> >     45 00 05 dc fd 34 20 b9 40 11 d2 a2 c0 a8 01 c8  E....4 .@.......
> >   backtrace:
> >     [<c00ab5d8>] __save_stack_trace+0x34/0x40
> >     [<c00ab6e8>] create_object+0x104/0x1fc
> >     [<c0326a90>] kmemleak_alloc+0x40/0x84
> >     [<c00a8fb0>] __kmalloc_track_caller+0x144/0x15c
> >     [<c028b048>] __alloc_skb+0x54/0x108
> >     [<c028bc7c>] dev_alloc_skb+0x20/0x44
> >     [<c02035e4>] emac_net_alloc_rx_buf+0x24/0xa8
> >     [<c02047e8>] emac_poll+0x244/0x5d0
> >     [<c0292af4>] net_rx_action+0xb4/0x274
> >     [<c004f648>] __do_softirq+0xb0/0x164
> >     [<c004f75c>] irq_exit+0x60/0xb8
> >     [<c0035074>] asm_do_IRQ+0x74/0x8c
> >     [<c0035ad8>] __irq_svc+0x58/0xa4
> >     [<c0036fac>] cpu_idle+0x80/0xf0
> >     [<c0326478>] rest_init+0x70/0x84
> >     [<c00089dc>] start_kernel+0x28c/0x2e4
> > ......
> > (the output is too long and the backtrace is almost the same as above)
> >
> > Is this real kernel memory leaks, or it's only transient?
>
> In general, the Linux kernel tries to cache as much data in memory as
> possible in order to improve performance.  Therefore, it is quite
> normal to see decreasing free memory over time.  As long as the kernel
> is able to free memory cache when needed, there are no issues.
>
> Regards,
>
> Steve
>

Thanks for your reply. Maybe the kernel caches sk_buff, but kmemleak
considers them as unreferenced object. I find that the addresses of the
"unreferenced object" reported by kmemleak always change, if they are real
memory leaks, the addresses should be fixed, am I right?

-- 
Yinglin Luan
Best Regards
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Reply via email to