Re: OOM panics with zram

Nitin Gupta
2010-10-03T19:41:01Z

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