search

mfrw / compcache

Automatically exported from code.google.com/p/compcache
0 stars 0 forks source link

crash with repeated cycles of memhog (x86 and x64) #19

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. run:

a=1
while ((1)); do
    echo "Loop: $a"
    a=$((a = a + 1))"
    cat /proc/swaps
    cat /proc/compcache
    memhog 512m
done

2. Both on x86 and x86_64, system freezes within 5 iterations (1st
iteration is always successful).

3. System: Fedora Linux VMs:
    arch: x86, x64
    mem: 512m
    vcpus: 1

What is the expected output? What do you see instead?

System freezes with nothing useful in syslog. Issued flushes after crash
using sysrq but still nothing useful in logs.

Please use labels and text to provide additional information.

Screenshots attached.

Original issue reported on code.google.com by nitingupta910@gmail.com on 31 Dec 2008 at 1:49

Attachments:

GoogleCodeExporter commented 9 years ago 
This system freeze is happening since we are calling kmap() inside spin lock in
xvmalloc. kmap() can cause a reschedule which is a big NO inside spin lock.

Here is the serial o/p for crash:

BUG: spinlock cpu recursion on CPU#0, kswapd0/262  <--- cause: sched under spin 
lock
 lock: debc8044, .magic: dead4ead, .owner: memhog/2690, .owner_cpu: 0
Pid: 262, comm: kswapd0 Not tainted 2.6.28 #2
Call Trace:
 [<c075f8c6>] ? printk+0x1d/0x1f
 [<c0599bb3>] spin_bug+0xa3/0xf0
 [<c0599d14>] _raw_spin_lock+0x74/0x140
 [<e15853b5>] ? xvFree+0x35/0x1c0 [xvmalloc]
 [<e1585599>] ? xvMalloc+0x59/0x200 [xvmalloc]
 [<c0762de7>] _spin_lock+0x57/0x70
 [<e15853b5>] ? xvFree+0x35/0x1c0 [xvmalloc]
 [<e15853b5>] xvFree+0x35/0x1c0 [xvmalloc]
 [<e15b53d4>] compcache_make_request+0x2c4/0x4c0 [compcache]
 [<c057c6f4>] generic_make_request+0x3c4/0x4b0
 [<c0463457>] ? __lock_acquire+0x297/0x1160
 [<c04c6355>] ? kmem_cache_alloc+0xc5/0x120
 [<c049e423>] ? mempool_alloc_slab+0x13/0x20
 [<c0409531>] ? sched_clock+0x11/0x20
 [<c046195d>] ? lock_release_holdtime+0x2d/0x210
 [<c04a9faa>] ? inc_zone_page_state+0x5a/0x90
 [<c057c847>] submit_bio+0x67/0xf0
 [<c0462f0b>] ? trace_hardirqs_on+0xb/0x10
 [<c04a3b95>] ? test_set_page_writeback+0x75/0x120
 [<c04b8e26>] swap_writepage+0x76/0xb0
 [<c04b8e60>] ? end_swap_bio_write+0x0/0x90
 [<c04a7245>] shrink_page_list+0x615/0x830
 [<c0409531>] ? sched_clock+0x11/0x20
 [<c046195d>] ? lock_release_holdtime+0x2d/0x210
 [<c04a7f8c>] shrink_zone+0x4dc/0x8f0
 [<c0762c02>] ? _spin_unlock+0x22/0x30
 [<c04a8c3b>] kswapd+0x52b/0x550
 [<c04a7530>] ? isolate_pages_global+0x0/0x200
 [<c04509f0>] ? autoremove_wake_function+0x0/0x50
 [<c04a8710>] ? kswapd+0x0/0x550
 [<c04506a1>] kthread+0x41/0x80
 [<c0450660>] ? kthread+0x0/0x80
 [<c0404c7b>] kernel_thread_helper+0x7/0x10

Original comment by nitingupta910@gmail.com on 5 Jan 2009 at 4:42

GoogleCodeExporter commented 9 years ago 
This is fixed in SVN rev #151

Original comment by nitingupta910@gmail.com on 5 Jan 2009 at 4:43

GoogleCodeExporter commented 9 years ago

Original comment by nitingupta910@gmail.com on 5 Jan 2009 at 4:43

GoogleCodeExporter commented 9 years ago 
Tested on both x86 and x64 with 50+ memhog cycles.

Original comment by nitingupta910@gmail.com on 5 Jan 2009 at 4:49

GoogleCodeExporter commented 9 years ago 
Fixed in compcache-0.5.1

Original comment by nitingupta910@gmail.com on 27 Jan 2009 at 11:14