public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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?

  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