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]>
---------
(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"




                                                                           
             Subrata Modak                                                 
             <[EMAIL PROTECTED]                                             
             et.ibm.com>                                                To 
                                       ltp-list                            
             08/25/2008 09:51          <[email protected]>    
             PM                                                         cc 
                                       Jin Bing Guo/China/[EMAIL PROTECTED],    
   
                                       Masatake YAMATO                     
             Please respond to         <[EMAIL PROTECTED]>,                
             [EMAIL PROTECTED]         "santwana.samantray"                
                 t.ibm.com             <[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
 [<c01584f5>] oom_kill_process+0x105/0x110
 [<c0158890>] out_of_memory+0x100/0x160
 [<c015a8f6>] __alloc_pages+0x316/0x360
 [<c012abe5>] do_softirq+0x85/0x90
 [<c017a067>] cache_alloc_refill+0x337/0x5c0
 [<c0105c81>] hypervisor_callback+0x3d/0x48
 [<c0179d1b>] kmem_cache_alloc+0x8b/0xa0
 [<c02a1bd3>] __alloc_skb+0x33/0x110
 [<c029e14d>] sock_alloc_send_skb+0x17d/0x1f0
 [<c02a2b77>] memcpy_fromiovec+0x37/0x50
 [<c030a68e>] unix_stream_sendmsg+0x21e/0x3c0
 [<c029ab53>] do_sock_write+0xa3/0xd0
 [<c029bc95>] sock_aio_write+0x75/0x80
 [<c01097a7>] profile_pc+0x37/0x80
 [<c017dc34>] do_sync_write+0xc4/0x100
 [<c013b240>] autoremove_wake_function+0x0/0x40
 [<c012aac6>] __do_softirq+0x86/0x120
 [<c017e7da>] vfs_write+0x16a/0x1a0
 [<c017ef53>] sys_write+0x53/0x90
 [<c0105aad>] 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


<<inline: graycol.gif>>

<<inline: pic01630.gif>>

<<inline: ecblank.gif>>

Attachment: Fix_memory_leak_hackbench.patch
Description: Binary data

-------------------------------------------------------------------------
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