From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754803Ab0JCTlB (ORCPT ); Sun, 3 Oct 2010 15:41:01 -0400 Received: from mail-qw0-f46.google.com ([209.85.216.46]:36903 "EHLO mail-qw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754705Ab0JCTlA (ORCPT ); Sun, 3 Oct 2010 15:41:00 -0400 Message-ID: <4CA8DC47.5070003@vflare.org> Date: Sun, 03 Oct 2010 15:40:55 -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 , Greg KH - Meetings Subject: Re: OOM panics with zram References: <1281374816-904-1-git-send-email-ngupta@vflare.org> <1284053081.7586.7910.camel@nimitz> <4CA8CE45.9040207@vflare.org> <1286134073.9970.11.camel@nimitz> In-Reply-To: <1286134073.9970.11.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 On 10/3/2010 3:27 PM, Dave Hansen wrote: > On Sun, 2010-10-03 at 14:41 -0400, Nitin Gupta wrote: >> 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. > > I'd argue that zram is pretty useless without some ability to write to a > backing store, unless you *really* know what is going to be stored in it > and you trust the user. Otherwise, it's just too easy to OOM the > system. > > I've been investigating backing the xvmalloc space with a tmpfs file. > Instead of keeping page/offset pairs, you just keep a linear address > inside the tmpfile file. There's an extra step needed to look up and > lock the page cache page into place each time you go into the xvmalloc > store, but it does seem to basically work. The patches are really rough > and not quite functional, but I'm happy to share if you want to see them > now. > Yes, I would be really interested to look at them. Thanks. >> 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. > > That looks like just a clone of the code needed to build the module. > > Kernel developers are pretty used to _some_ kernel tree being the > authoritative source. Also, having it in a kernel tree makes it > possible to get testing in places like linux-next, and it makes it > easier for people to make patches or kernel trees on top of your work. > > There's not really a point to the code being in -staging if it isn't > somewhat up-to-date or people can't generate patches to it. It sounds > to me like we need to take it out of -staging. > I will try sending patches to sync mainline and hg code (along with some changes in pipeline), or maybe just take it out of -staging and send fresh patch series. Thanks, Nitin From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail137.messagelabs.com (mail137.messagelabs.com [216.82.249.19]) by kanga.kvack.org (Postfix) with SMTP id BF37B6B0047 for ; Sun, 3 Oct 2010 15:41:01 -0400 (EDT) Received: by qyk33 with SMTP id 33so387793qyk.14 for ; Sun, 03 Oct 2010 12:41:00 -0700 (PDT) Message-ID: <4CA8DC47.5070003@vflare.org> Date: Sun, 03 Oct 2010 15:40:55 -0400 From: Nitin Gupta MIME-Version: 1.0 Subject: Re: OOM panics with zram References: <1281374816-904-1-git-send-email-ngupta@vflare.org> <1284053081.7586.7910.camel@nimitz> <4CA8CE45.9040207@vflare.org> <1286134073.9970.11.camel@nimitz> In-Reply-To: <1286134073.9970.11.camel@nimitz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org To: Dave Hansen Cc: Pekka Enberg , Minchan Kim , Andrew Morton , Greg KH , Linux Driver Project , linux-mm , linux-kernel , Greg KH - Meetings List-ID: On 10/3/2010 3:27 PM, Dave Hansen wrote: > On Sun, 2010-10-03 at 14:41 -0400, Nitin Gupta wrote: >> 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. > > I'd argue that zram is pretty useless without some ability to write to a > backing store, unless you *really* know what is going to be stored in it > and you trust the user. Otherwise, it's just too easy to OOM the > system. > > I've been investigating backing the xvmalloc space with a tmpfs file. > Instead of keeping page/offset pairs, you just keep a linear address > inside the tmpfile file. There's an extra step needed to look up and > lock the page cache page into place each time you go into the xvmalloc > store, but it does seem to basically work. The patches are really rough > and not quite functional, but I'm happy to share if you want to see them > now. > Yes, I would be really interested to look at them. Thanks. >> 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. > > That looks like just a clone of the code needed to build the module. > > Kernel developers are pretty used to _some_ kernel tree being the > authoritative source. Also, having it in a kernel tree makes it > possible to get testing in places like linux-next, and it makes it > easier for people to make patches or kernel trees on top of your work. > > There's not really a point to the code being in -staging if it isn't > somewhat up-to-date or people can't generate patches to it. It sounds > to me like we need to take it out of -staging. > I will try sending patches to sync mainline and hg code (along with some changes in pipeline), or maybe just take it out of -staging and send fresh patch series. Thanks, Nitin -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org