From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754590Ab0JCSlW (ORCPT ); Sun, 3 Oct 2010 14:41:22 -0400 Received: from mail-qw0-f46.google.com ([209.85.216.46]:51791 "EHLO mail-qw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751278Ab0JCSlV (ORCPT ); Sun, 3 Oct 2010 14:41:21 -0400 Message-ID: <4CA8CE45.9040207@vflare.org> Date: Sun, 03 Oct 2010 14:41:09 -0400 From: Nitin Gupta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Dave Hansen CC: Pekka Enberg , Minchan Kim , Andrew Morton , Greg KH , Linux Driver Project , linux-mm , linux-kernel Subject: Re: OOM panics with zram References: <1281374816-904-1-git-send-email-ngupta@vflare.org> <1284053081.7586.7910.camel@nimitz> In-Reply-To: <1284053081.7586.7910.camel@nimitz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Dave, Sorry for late reply. Since last month I couldn't get any chance to work on this project. On 9/9/2010 1:24 PM, Dave Hansen wrote: > > 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] [] panic+0xba/0x1e0 > [703826.026801] [] ? next_online_pgdat+0x21/0x50 > [703826.032799] [] ? find_lock_task_mm+0x23/0x60 > [703826.038795] [] ? dump_header+0x19b/0x1b0 > [703826.044446] [] out_of_memory+0x297/0x2d0 > [703826.050098] [] __alloc_pages_nodemask+0x72f/0x740 > [703826.056528] [] ? __set_page_dirty+0x6e/0xc0 > [703826.062438] [] alloc_pages_current+0x87/0xd0 > [703826.068438] [] __page_cache_alloc+0xb/0x10 > [703826.074263] [] __do_page_cache_readahead+0xdf/0x220 > [703826.080865] [] ra_submit+0x1c/0x20 > [703826.085998] [] ondemand_readahead+0xa8/0x1d0 > [703826.091994] [] page_cache_async_readahead+0x77/0xc0 > [703826.098595] [] generic_file_aio_read+0x259/0x6d0 > [703826.104941] [] do_sync_read+0xd1/0x110 > [703826.110418] [] vfs_read+0xc6/0x170 > [703826.115547] [] sys_read+0x50/0x90 > [703826.120591] [] 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? > Ability to write out zram (compressed) memory to a backing disk seems really useful. However considering lkml reviews, I had to drop this feature. Anyways, I guess I will try to push this feature again. Also, please do not use linux-next/mainline version of compcache. Instead just use version in the project repository here: hg clone https://compcache.googlecode.com/hg/ compcache This is updated much more frequently and has many more bug fixes over the mainline. It will also be easier to fix bugs/add features much more quickly in this repo rather than sending them to lkml which can take long time. Thanks, Nitin