Message-Id: <201010040708.27939.edt@aei.ca>
Date:	Mon, 4 Oct 2010 07:08:27 -0400
From:	Ed Tomlinson <edt@....ca>
To:	Nitin Gupta <ngupta@...are.org>
Cc:	Dave Hansen <dave@...ux.vnet.ibm.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Minchan Kim <minchan.kim@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg KH <greg@...ah.com>,
	Linux Driver Project <devel@...uxdriverproject.org>,
	"linux-mm" <linux-mm@...ck.org>,
	"linux-kernel" <linux-kernel@...r.kernel.org>,
	"Greg KH - Meetings" <ghartman@...ibm.com>
Subject: Re: OOM panics with zram

On Sunday 03 October 2010 15:40:55 Nitin Gupta wrote:
> 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.

Or move it to a git tree.  Then generating patches becomes tivial for all of
us and keeping staging upto date becomes easier for you.

Ed

> Thanks,
> Nitin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists