Message-ID: <4C0A005A.10607@vflare.org>
Date:	Sat, 05 Jun 2010 13:14:26 +0530
From:	Nitin Gupta <ngupta@...are.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	Greg KH <greg@...ah.com>, Pekka Enberg <penberg@...helsinki.fi>,
	Minchan Kim <minchan.kim@...il.com>, Ed Tomlinson <edt@....ca>,
	Hugh Dickins <hugh.dickins@...cali.co.uk>,
	Cyp <cyp561@...il.com>, driverdev <devel@...verdev.osuosl.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] Support generic I/O requests

On 06/05/2010 12:40 AM, Andrew Morton wrote:
> On Tue,  1 Jun 2010 13:31:23 +0530
> Nitin Gupta <ngupta@...are.org> 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

--
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