Commit a1dd52af authored by Nitin Gupta's avatar Nitin Gupta Committed by Greg Kroah-Hartman

Staging: ramzswap: Support generic I/O requests

Currently, ramzwap devices (/dev/ramzswapX) can only
be used as swap disks since it was hard-coded to consider
only the first request in bio vector.

Now, we iterate over all the segments in an incoming
bio which allows us to handle all kinds of I/O requests.

ramzswap devices can still handle PAGE_SIZE aligned and
multiple of PAGE_SIZE sized I/O requests only. To ensure
that we get always get such requests only, we set following
request_queue attributes to PAGE_SIZE:
 - physical_block_size
 - logical_block_size
 - io_min
 - io_opt

Note: physical and logical block sizes were already set
equal to PAGE_SIZE and that seems to be sufficient to get
PAGE_SIZE aligned I/O.

Since we are no longer limited to handling swap requests
only, the next few patches rename ramzswap to zram. So,
the devices will then be called /dev/zram{0, 1, 2, ...}

Usage/Examples:
 1) Use as /tmp storage
 - mkfs.ext4 /dev/zram0
 - mount /dev/zram0 /tmp

 2) Use as swap:
 - mkswap /dev/zram0
 - swapon /dev/zram0 -p 10 # give highest priority to zram0

Performance:

 - I/O benchamark done with 'dd' command. Details can be
found here:
http://code.google.com/p/compcache/wiki/zramperf
Summary:
 - Maximum read speed (approx):
   - ram disk: 1200 MB/sec
   - zram disk: 600 MB/sec
 - Maximum write speed (approx):
   - ram disk: 500 MB/sec
   - zram disk: 160 MB/sec

Issues:

 - Double caching: We can potentially waste memory by having
two copies of a page -- one in page cache (uncompress) and
second in the device memory (compressed). However, during
reclaim, clean page cache pages are quickly freed, so this
does not seem to be a big problem.

 - Stale data: Not all filesystems support issuing 'discard'
requests to underlying block devices. So, if such filesystems
are used over zram devices, we can accumulate lot of stale
data in memory. Even for filesystems to do support discard
(example, ext4), we need to see how effective it is.

 - Scalability: There is only one (per-device) de/compression
buffer stats. This can lead to significant contention, especially
when used for generic (non-swap) purposes.
Signed-off-by: default avatarNitin Gupta <ngupta@vflare.org>
Acked-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
parent 36e574fe
This diff is collapsed.
......@@ -112,7 +112,8 @@ struct ramzswap {
void *compress_buffer;
struct table *table;
spinlock_t stat64_lock; /* protect 64-bit stats */
struct mutex lock;
struct mutex lock; /* protect compression buffers against
* concurrent writes */
struct request_queue *queue;
struct gendisk *disk;
int init_done;
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment