On 06/05/2010 12:40 AM, Andrew Morton wrote: > On Tue, 1 Jun 2010 13:31:23 +0530 > Nitin Gupta <ngupta@xxxxxxxxxx> wrote: > >> Usage/Examples: >> 1) Use as /tmp storage >> - mkfs.ext4 /dev/zram0 >> - mount /dev/zram0 /tmp > > hm, how does that work? The "device" will only handle page-sized and > page-aligned requests, won't it? Can you walk us through what happens > when the fs does a 512-byte I/O? > Yes, it still handles page-size aligned, n*page_size sized I/O requests. Unfortunately, I don't know much of vfs/filesystem details, so I could not trace out the exact path. But, given that we set logical and physical sector size to PAGE_SIZE, the block layer (and filesytem) should make sure that we get correctly aligned, correctly sized I/O requests. I just discovered this fact through experimentation and didn't know making it a generic device is actually this easy. Given that I lack detailed knowledge in this area, there may be some corner cases where we may get unaligned I/O requests (in which case we simply return I/O error) but successful run of 'dd' and 'iozone' tests (links in patch 0/4) increased my confidence in this :) The only change that was needed to make it generic device was to iterate over all bio segments (earlier it was hard-coded to handle just the first one). >> - 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. > > Yes, clean pagecache is cheap. But what happens when the pagecache > copy of the page gets modified? > Dirty pages are periodically flushed to disk (zram in this case) and then it becomes clean again. > Or is it the case that once a compressed page gets copied out to > pagecache, the compressed version is never used again? If so, the > memory could be synchronously freed, so I guess I don't understand what > you mean here. We cannot free a page as soon as it is decompressed and added to page cache. When a clean page is reclaimed, it is simply freed and not written out to disk and thus, we will end up losing this data. The only opportunity to free a (compressed) disk page is when filesystem issues a block discard request or, when used as a swap disk, we get a swap slot free notification (a callback for this was recently added to struct block_device_operations). > >> - 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. > > Can you walk us through how zram uses discard requests? > I could not get discard working (yet), so support for this was removed from these patches. I hope to include it soon. Thanks for your feedback. Nitin _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
