On Tue, Nov 29, 2011 at 6:39 PM, Dmitry Panov <dmitry.pa...@yahoo.co.uk> wrote:
> 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?
>

Yes (sort of).
OOM does not happen but swapoff() seems to run forever.
It's looks like the kernel is unable to unuse swapped pages.

-- 
Thanks,
//richard

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

Reply via email to