On Wed, 2008-08-27 at 12:14 +0800, Jin Bing Guo wrote:
> I didn't see the oom-killer in my test machines. But I found large
> memory leak of the Hackbench with valgrind tool.
> (http://valgrind.org/)
> 
> # valgrind --leak-check=full --show-reachable=yes ./hackbench 1
> process 1000
> ==24500== LEAK SUMMARY:
> ==24500== definitely lost: 492 bytes in 21 blocks.
> ==24500== possibly lost: 0 bytes in 0 blocks.
> ==24500== still reachable: 160 bytes in 1 blocks.
> ==24500== suppressed: 0 bytes in 0 blocks.
> # valgrind --leak-check=full --show-reachable=yes ./hackbench 20
> process 1000
> ==24597== LEAK SUMMARY:
> ==24597== definitely lost: 9,840 bytes in 420 blocks.
> ==24597== possibly lost: 0 bytes in 0 blocks.
> ==24597== still reachable: 3,200 bytes in 1 blocks.
> ==24597== suppressed: 0 bytes in 0 blocks.
> 
> From that we can get that it will lose 73,800 bytes with running
> "hackbench 150 process 1000" once. 
> This patch fixed the memory leak problem. 
> ============
> After patching
> ============
> # valgrind --leak-check=full --show-reachable=yes ./hackbench 20
> process 1000
> ==26495== 
> ==26495== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from
> 1)
> ==26495== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==26495== malloc/free: 423 allocs, 423 frees, 14,720 bytes allocated.
> ==26495== For counts of detected errors, rerun with: -v
> ==26495== All heap blocks were freed -- no leaks are possible.
> 
> 
> Santwana, could you test this patch if it resolved the oom-killer
> problem of Hackbench? Thanks.
> 
> Signed-off-by: Jin Bing Guo <[EMAIL PROTECTED]>

I just checked it out. I think even if it does not solve the OOM-killer
problem (the reason is still unknown), it does solve the problem of
memory leak. I tested it and got the following output post patching:

$ ./testcases/kernel/sched/cfs-scheduler/hackbench 20 process 1000
Running with 20*40 (== 800) tasks.
Time: 22.650
$ echo $?
0

So, i would prefer to merge this patch for solving the memory leak
problem. However investigation for the oom-killer can continue. Thanks.

Regards--
Subrata


> ---------
> (See attached file: Fix_memory_leak_hackbench.patch)
> 
> 
> Best regards!
> 
> Jin Bing Guo 郭晋兵
> 
> Linux for System p Test
> IBM China Systems & Technology Laboratory in Beijing
> Tel: +86-10-82454439 
> Email: [EMAIL PROTECTED]
> -------------------------------------
> "Do today what others won't so tomorrow you do what other's can't" 
> 
> 
> 
> Inactive hide details for Subrata Modak ---08/25/2008 10:07:19
> PM---Hi,Subrata Modak ---08/25/2008 10:07:19 PM---Hi,
> 
>                                 Subrata Modak <[EMAIL PROTECTED]> 
>                                 
>                                 08/25/2008 09:51 PM 
>                                 Please respond to
>                                 [EMAIL PROTECTED]
>                                 
> 
>                To
> 
> ltp-list
> <[email protected]>
> 
>                cc
> 
> Jin Bing
> Guo/China/[EMAIL PROTECTED], Masatake YAMATO <[EMAIL PROTECTED]>, 
> "santwana.samantray" <[EMAIL PROTECTED]>, Rusty Russell <[EMAIL PROTECTED]>, 
> Pierre Peiffer <[EMAIL PROTECTED]>, Ingo Molnar <[EMAIL PROTECTED]>, Arjan 
> van de Ven <[EMAIL PROTECTED]>, "Zhang, Yanmin" <[EMAIL PROTECTED]>, Nathan 
> Lynch <[EMAIL PROTECTED]>, bnpoorni <[EMAIL PROTECTED]>, Edjunior Barbosa 
> Machado <[EMAIL PROTECTED]>, "anoop.vijayan" <[EMAIL PROTECTED]>, 
> "iranna.ankad" <[EMAIL PROTECTED]>, maknayak <[EMAIL PROTECTED]>, risrajak 
> <[EMAIL PROTECTED]>, supriyak <[EMAIL PROTECTED]>
> 
>           Subject
> 
> [LTP] Hackbench
> invoked
> oom-killer, while
> running ltp
> runall
> 
> 
> 
> Hi,
> 
> While testing, Santwana has encountered that Hackbench invoked
> oom-killer, while running ltp runall. It has been recently ported to
> LTP
> from the Original program available at Red Hat site, and, has
> undergone
> few changes satisfying to LTP´s needs. The program can be found here:
> 
> http://ltp.cvs.sourceforge.net/ltp/ltp/testcases/kernel/sched/cfs-scheduler/hackbench.c,
> 
> and the ways it is invoked is:
> 
> hackbench01 hackbench 150 process 1000
> hackbench02 hackbench 20 thread 1000
> 
> Jin/Yamato,
> 
> Have you encountered oom-killer while executing Hackbench ? I doubt
> that
> it has got to do with the way we invoke hackbench01 test. We can
> instead
> change this to:
> 
> hackbench01 hackbench 20 process 1000,
> from
> hackbench01 hackbench 150 process 1000,
> 
> and see whether this can solve this problem.
> 
> Santwana,
> Can you see whether this works out ?
> 
> Following are the various details of the error encountered:
> 
> ---uname output---
> Linux 2.6.16.60-0.21-xenpae #1 SMP Tue May 6 12:41:02 UTC 2008 i686
> i686
> i386 GNU/Linux,
> 
> ---Steps to Reproduce---
> Run ltp by issuing:
> nohup ./runltp -p -q -l [logfile name] -o [outputfile name] -t 24h &
> 
> oom-killer is noticed in dmesg as well as /var/log/messages.
> hackbench invoked oom-killer: gfp_mask=0x4d0, order=0, oomkilladj=0
> oom_kill_process+0x105/0x110
> out_of_memory+0x100/0x160
> __alloc_pages+0x316/0x360
> do_softirq+0x85/0x90
> cache_alloc_refill+0x337/0x5c0
> hypervisor_callback+0x3d/0x48
> kmem_cache_alloc+0x8b/0xa0
> __alloc_skb+0x33/0x110
> sock_alloc_send_skb+0x17d/0x1f0
> memcpy_fromiovec+0x37/0x50
> unix_stream_sendmsg+0x21e/0x3c0
> do_sock_write+0xa3/0xd0
> sock_aio_write+0x75/0x80
> profile_pc+0x37/0x80
> do_sync_write+0xc4/0x100
> autoremove_wake_function+0x0/0x40
> __do_softirq+0x86/0x120
> vfs_write+0x16a/0x1a0
> sys_write+0x53/0x90
> syscall_call+0x7/0xb
> 
> 
> Mem-info:
> DMA per-cpu:
> CPU    0: Hot: hi:    0, btch:   1 usd:   0   Cold: hi:    0, btch:
> 1 usd:   0
> CPU    1: Hot: hi:    0, btch:   1 usd:   0   Cold: hi:    0, btch:
> 1 usd:   0
> CPU    2: Hot: hi:    0, btch:   1 usd:   0   Cold: hi:    0, btch:
> 1 usd:   0
> CPU    3: Hot: hi:    0, btch:   1 usd:   0   Cold: hi:    0, btch:
> 1 usd:   0
> CPU    4: Hot: hi:    0, btch:   1 usd:   0   Cold: hi:    0, btch:
> 1 usd:   0
> CPU    5: Hot: hi:    0, btch:   1 usd:   0   Cold: hi:    0, btch:
> 1 usd:   0
> CPU    6: Hot: hi:    0, btch:   1 usd:   0   Cold: hi:    0, btch:
> 1 usd:   0
> CPU    7: Hot: hi:    0, btch:   1 usd:   0   Cold: hi:    0, btch:
> 1 usd:   0
> Normal per-cpu:
> CPU    0: Hot: hi:  186, btch:  31 usd:  34   Cold: hi:   62, btch:
>  15 usd:  55
> CPU    1: Hot: hi:  186, btch:  31 usd:  13   Cold: hi:   62, btch:
>  15 usd:  61
> CPU    2: Hot: hi:  186, btch:  31 usd: 151   Cold: hi:   62, btch:
>  15 usd:  56
> CPU    3: Hot: hi:  186, btch:  31 usd:  44   Cold: hi:   62, btch:
>  15 usd:  50
> CPU    4: Hot: hi:  186, btch:  31 usd:   3   Cold: hi:   62, btch:
>  15 usd:  60
> CPU    5: Hot: hi:  186, btch:  31 usd:  59   Cold: hi:   62, btch:
>  15 usd:  53
> CPU    6: Hot: hi:  186, btch:  31 usd:   3   Cold: hi:   62, btch:
>  15 usd:  53
> CPU    7: Hot: hi:  186, btch:  31 usd:  31   Cold: hi:   62, btch:
>  15 usd:  61
> HighMem per-cpu:
> CPU    0: Hot: hi:  186, btch:  31 usd:  30   Cold: hi:   62, btch:
>  15 usd:   0
> CPU    1: Hot: hi:  186, btch:  31 usd: 115   Cold: hi:   62, btch:
>  15 usd:   7
> CPU    2: Hot: hi:  186, btch:  31 usd: 116   Cold: hi:   62, btch:
>  15 usd:   9
> CPU    3: Hot: hi:  186, btch:  31 usd: 164   Cold: hi:   62, btch:
>  15 usd:  11
> CPU    4: Hot: hi:  186, btch:  31 usd: 177   Cold: hi:   62, btch:
>  15 usd:   8
> CPU    5: Hot: hi:  186, btch:  31 usd: 180   Cold: hi:   62, btch:
>  15 usd:   9
> CPU    6: Hot: hi:  186, btch:  31 usd: 146   Cold: hi:   62, btch:
>  15 usd:  38
> CPU    7: Hot: hi:  186, btch:  31 usd: 150   Cold: hi:   62, btch:
>  15 usd:   0
> Free pages:     8003600kB (7997324kB HighMem)
> Active:74821 inactive:3038 dirty:19 writeback:0 unstable:0
> free:2000900
> slab:118580 mapped:872 pagetables:24268
> DMA free:2912kB min:72kB low:88kB high:108kB active:0kB inactive:0kB
> present:16384kB pages_scanned:0 all_unreclaimable? yes
> lowmem_reserve[]: 0 0 711 8835
> Normal free:3364kB min:3376kB low:4220kB high:5064kB active:116kB
> inactive:116kB
> present:729080kB pages_scanned:0 all_unreclaimable? no
> lowmem_reserve[]: 0 0 0 64990
> HighMem free:7997324kB min:512kB low:10140kB high:19772kB
> active:299168kB
> inactive:12036kB present:8318816kB pages_scanned:0 all_unreclaimable?
> no
> lowmem_reserve[]: 0 0 0 0
> DMA: 0*4kB 0*8kB 0*16kB 1*32kB 1*64kB 0*128kB 1*256kB 1*512kB 0*1024kB
> 1*2048kB
> 0*4096kB = 2912kB
> Normal: 15*4kB 1*8kB 0*16kB 3*32kB 0*64kB 1*128kB 0*256kB 0*512kB
> 1*1024kB
> 1*2048kB 0*4096kB = 3364kB
> HighMem: 95*4kB 2*8kB 2*16kB 1*32kB 1*64kB 87*128kB 754*256kB
> 598*512kB
> 345*1024kB 245*2048kB 1619*4096kB = 7997324kB
> Swap cache: add 216841, delete 215153, find 407/493, race 0+0
> Free swap  = 4163536kB
> Total swap = 4200988kB
> Free swap:       4163536kB
> 2266070 pages of RAM
> 2079704 pages of HIGHMEM
> 38075 reserved pages
> 305938 pages shared
> 1690 pages swap cached
> 19 pages dirty
> 0 pages writeback
> 872 pages mapped
> 118533 pages slab
> 24268 pages pagetables
> 
> 
> Regards--
> Subrata
> 
> 
> 
> 
> 


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Reply via email to