From: Andrew Morton <akpm@linux-foundation.org>
To: Nitin Gupta <ngupta@vflare.org>
Cc: Greg KH <greg@kroah.com>, Pekka Enberg <penberg@cs.helsinki.fi>,
Minchan Kim <minchan.kim@gmail.com>, Ed Tomlinson <edt@aei.ca>,
Hugh Dickins <hugh.dickins@tiscali.co.uk>, Cyp <cyp561@gmail.com>,
driverdev <devel@driverdev.osuosl.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/4] Support generic I/O requests
Date: Fri, 4 Jun 2010 12:10:41 -0700 [thread overview]
Message-ID: <20100604121041.1b88b0af.akpm@linux-foundation.org> (raw)
In-Reply-To: <1275379286-10453-2-git-send-email-ngupta@vflare.org>
On Tue, 1 Jun 2010 13:31:23 +0530
Nitin Gupta <ngupta@vflare.org> wrote:
> 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, ...}
Thanks for doing this - I think it's for the best..
> 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?
> - 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?
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.
> - 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?
next prev parent reply other threads:[~2010-06-04 19:11 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-01 8:01 [PATCH 0/4] zram: generic RAM based compressed R/W block devices (v2) Nitin Gupta
2010-06-01 8:01 ` [PATCH 1/4] Support generic I/O requests Nitin Gupta
2010-06-02 6:20 ` Minchan Kim
2010-06-02 7:36 ` Nitin Gupta
2010-06-04 19:19 ` Andrew Morton
2010-06-05 8:28 ` Pekka Enberg
2010-06-05 8:36 ` Pekka Enberg
2010-06-05 8:35 ` Pekka Enberg
2010-06-05 13:15 ` Nitin Gupta
2010-06-06 23:32 ` Minchan Kim
2010-06-07 5:35 ` Pekka Enberg
2010-06-04 19:10 ` Andrew Morton [this message]
2010-06-05 7:44 ` Nitin Gupta
2010-06-01 8:01 ` [PATCH 2/4] Rename ramzswap files to zram Nitin Gupta
2010-06-04 19:32 ` Andrew Morton
2010-06-04 21:07 ` Greg KH
2010-06-05 7:00 ` Nitin Gupta
2010-06-01 8:01 ` [PATCH 3/4] Rename ramzswap to zram in code Nitin Gupta
2010-06-01 8:01 ` [PATCH 4/4] Rename ramzswap to zram in documentation Nitin Gupta
2010-06-01 10:25 ` [PATCH 0/4] zram: generic RAM based compressed R/W block devices (v2) Pekka Enberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100604121041.1b88b0af.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=cyp561@gmail.com \
--cc=devel@driverdev.osuosl.org \
--cc=edt@aei.ca \
--cc=greg@kroah.com \
--cc=hugh.dickins@tiscali.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=minchan.kim@gmail.com \
--cc=ngupta@vflare.org \
--cc=penberg@cs.helsinki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox