zram with backing swap and dynamic memory usage

[GoogleCodeExporter]

Two issues,

1) OK I saw the reasons for removing backing swap support, and I agree for the 
reasons. Nevertheless, I see poor efficient use of memory, at least to "top" or 
"free". Backing swap would be nice in the end.... This leads me to next point. 

2) I'd like to see dynamic memory usage of the zram module.

For example, if I want to use it for swap, I might allocate 100MB of ram to 
zram swap. The problem here is that "swapon" only sees 100MB. Also 100MB is 
taken from normal RAM by zram, while it should only need 20-50% depending of 
the compression ratio.

So, to get to my point: Would it be possible to set a range/span of RAM for the 
zram module to use while showing a different size to swapon, or any other FS 
running ontop?

Original issue reported on code.google.com by ande...@gmail.com on 7 Feb 2011 at 6:13

[GoogleCodeExporter]

> For example, if I want to use it for swap, I might allocate 100MB of ram to 
zram swap. The problem here is that "swapon" only sees 100MB. Also 100MB is 
taken from normal RAM by zram, while it should only need 20-50% depending of 
the compression ratio.

When you create 100MB zram, we do not pre-allocate this 100MB but only few KBs 
of metadata overhead. Memory is allocated (and freed) for compressed pages only 
as needed. So, if compression ratio is 20% and zram as swap usage is 100% we 
only allocate (20% of 100MB + some wastage due to fragmentation + some metadata 
overhead).

All these statistics (total memory used, compression ratio and so on) through 
sysfs nodes (see README for details). Also, there is a small scripts in 
compcache/sub-projects/scripts/zram_stats which prints all these stats for you.

> So, to get to my point: Would it be possible to set a range/span of RAM for 
the zram module to use while showing a different size to swapon, or any other 
FS running ontop?

Due to the way block devices work, its not possible to set limit directly on 
the amount of memory assigned to *compressed* pages. You can only set limit on 
amount of uncompressed worth of data you can store. Then depending on the 
compression ratio (CR), you will end up allocate (CR * DiskSize) amount of 
memory (again, memory is not pre-allocated but alloc/free is done on-demand).

Original comment by nitingupta910@gmail.com on 8 Feb 2011 at 2:12

[GoogleCodeExporter]

Thank you for your response.

I did read the README etc and looked at the stats, however, I was confused 
because "top" instantly removed some memory available in its stats.

Then if it is as you mention, then there is no real trouble at all. 

Original comment by ande...@gmail.com on 8 Feb 2011 at 8:13

[GoogleCodeExporter]

Original comment by nitingupta910@gmail.com on 21 Jun 2011 at 3:05

• Changed state: Done