Hi guys,
I'm having an issue with swapoff which gets killed by OOM. I was able to
reproduce it with UML guests running different kernel versions, starting
from 2.6.26 to 3.1.3. The only difference is with latest kernels
sometimes it crashes instead of being killed. I haven't seen it on
'native' kernels so I guess it's UML specific.
Richard, I know I mentioned on the IRC yesterday that it was fine with
2.6.37, but I was wrong.
Basically this is the command line to start UML:
/usr/local/sbin/linux32.uml mem=160m elevator=noop
ubda=/home/uml/machines/static-fe02/root_cow.img,/opt/uml/shared/ia32_squeeze/images/root01.img
ubdb=swap.img root=/dev/ubda con0=fd:0,fd:1 con=pty
eth0=daemon,de:00:00:00:00:08,unix,/var/run/uml-utilities/uml_switch.ctl
umid=static-fe02 uml_dir=/root/.uml hostfs=/var/uml
swap.img is a solid file, 360M in size. Then inside the VM I ran the
following perl script:
#!/usr/bin/perl
my @a;
print "Filling...\n";
my $i = 0;
while ($i < 20000000) {
push @a, 1;
$i++;
}
print "Done.\n";
There is nothing magical about this script, it just makes sure some swap
is being used after it finishes.
static-fe02:~# free
total used free shared buffers cached
Mem: 158468 8524 149944 0 136 4016
-/+ buffers/cache: 4372 154096
Swap: 327672 2344 325328
There should be enough RAM to clear the swap, right? However if I run
swapoff -a, I get this:
swapoff invoked oom-killer: gfp_mask=0x1200d2, order=0, oomkilladj=0
1294cd74: [<081ea1a9>] dump_stack+0x1c/0x20
1294cd8c: [<08095712>] oom_kill_process+0x4b/0x166
1294cdb8: [<08095bcb>] out_of_memory+0x151/0x17e
1294cdf0: [<08097abf>] __alloc_pages_internal+0x299/0x33f
1294ce48: [<08097b8e>] __alloc_pages+0x13/0x15
1294ce54: [<080a506a>] read_swap_cache_async+0x40/0xab
1294ce7c: [<080a6583>] sys_swapoff+0x1ea/0x774
1294cf28: [<0805b017>] handle_syscall+0x7b/0x98
1294cf78: [<08068f72>] userspace+0x2cd/0x374
1294cfe0: [<08058d2b>] fork_handler+0x53/0x5b
1294cffc: [<00000000>] 0x0
Mem-info:
Normal per-cpu:
CPU 0: hi: 42, btch: 7 usd: 35
Active:200 inactive:1 dirty:0 writeback:0 unstable:0
free:456 slab:38427 mapped:0 pagetables:49 bounce:0
Normal free:1824kB min:1680kB low:2100kB high:2520kB active:800kB
inactive:4kB present:177112kB pages_scanned:422 all_unreclaimable? no
lowmem_reserve[]: 0 0
Normal: 42*4kB 1*8kB 1*16kB 1*32kB 1*64kB 0*128kB 0*256kB 1*512kB
1*1024kB 0*2048kB 0*4096kB = 1824kB
22 total pagecache pages
Swap cache: add 802082, delete 802082, find 30288/37816
Free swap = 4294965488kB
Total swap = 0kB
Free swap: -1808kB
44627 pages of RAM
0 pages of HIGHMEM
5010 reserved pages
20 pages shared
0 pages swap cached
Out of memory: kill process 646 (swapoff) score -1 or a child
Killed process 646 (swapoff)
Can anybody reproduce this?
Best regards,
--
Dmitry Panov
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
