OOM panics with zram

Dave Hansen
2010-09-09T17:24:46Z

Hi Nitin,

I've been playing with using zram (from -staging) to back some qemu
guest memory directly. Basically mmap()'ing the device in instead of
using anonymous memory. The old code with the backing swap devices
seemed to work pretty well, but I'm running into a problem with the new
code.

I have plenty of swap on the system, and I'd been running with compcache
nicely for a while. But, I went to go tar up (and gzip) a pretty large
directory in my qemu guest. It panic'd the qemu host system:

[703826.003126] Kernel panic - not syncing: Out of memory and no killable processes...
[703826.003127]
[703826.012350] Pid: 25508, comm: cat Not tainted 2.6.36-rc3-00114-g9b9913d #29
[703826.019385] Call Trace:
[703826.021928] [<ffffffff8104032a>] panic+0xba/0x1e0
[703826.026801] [<ffffffff810bb4a1>] ? next_online_pgdat+0x21/0x50
[703826.032799] [<ffffffff810a7713>] ? find_lock_task_mm+0x23/0x60
[703826.038795] [<ffffffff810a79ab>] ? dump_header+0x19b/0x1b0
[703826.044446] [<ffffffff810a8157>] out_of_memory+0x297/0x2d0
[703826.050098] [<ffffffff810abbaf>] __alloc_pages_nodemask+0x72f/0x740
[703826.056528] [<ffffffff81110d4e>] ? __set_page_dirty+0x6e/0xc0
[703826.062438] [<ffffffff810da477>] alloc_pages_current+0x87/0xd0
[703826.068438] [<ffffffff810a533b>] __page_cache_alloc+0xb/0x10
[703826.074263] [<ffffffff810ae2ff>] __do_page_cache_readahead+0xdf/0x220
[703826.080865] [<ffffffff810ae45c>] ra_submit+0x1c/0x20
[703826.085998] [<ffffffff810ae5f8>] ondemand_readahead+0xa8/0x1d0
[703826.091994] [<ffffffff810ae797>] page_cache_async_readahead+0x77/0xc0
[703826.098595] [<ffffffff810a6489>] generic_file_aio_read+0x259/0x6d0
[703826.104941] [<ffffffff810eac21>] do_sync_read+0xd1/0x110
[703826.110418] [<ffffffff810eb3f6>] vfs_read+0xc6/0x170
[703826.115547] [<ffffffff810eb860>] sys_read+0x50/0x90
[703826.120591] [<ffffffff81002c2b>] system_call_fastpath+0x16/0x1b

I have the feeling that the compcache device all of a sudden lost its
efficiency. It can't do much about having non-compressible data stuck
in it, of course.

But, it used to be able to write things out to backing storage. It
tries to return I/O errors when it runs out of space, but my system
didn't get that far. It panic'd before it got the chance.

This seems like an issue that will probably crop up when we use zram as
a swap device too. A panic seems like pretty undesirable behavior when
you've simply changed the kind of data being used. Have you run into
this at all?

-- Dave