LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Nitin Gupta <firstname.lastname@example.org>
To: Minchan Kim <email@example.com>
Cc: Dan Magenheimer <firstname.lastname@example.org>,
email@example.com, Chris Mason <firstname.lastname@example.org>,
email@example.com, firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, Kurt Hackel <email@example.com>,
Konrad Wilk <firstname.lastname@example.org>,
email@example.com, firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Subject: Re: [PATCH V2 2/3] drivers/staging: zcache: host services and PAM services
Date: Wed, 09 Feb 2011 20:17:41 -0500 [thread overview]
Message-ID: <4D533CB5.email@example.com> (raw)
On 02/09/2011 06:46 PM, Minchan Kim wrote:
> Hi Nitin,
> Sorry for late response.
> On Thu, Feb 10, 2011 at 2:36 AM, Nitin Gupta<firstname.lastname@example.org> wrote:
>> On 02/09/2011 11:39 AM, Dan Magenheimer wrote:
>>>> From: Minchan Kim [mailto:email@example.com]
>>>> As I read your comment, I can't find the benefit of zram compared to
>>> Well, I am biased, but I agree that frontswap is a better technical
>>> solution than zram. ;-) But "dynamic-ity" is very important to
>>> me and may be less important to others.
>> I agree that frontswap is better than zram when considering swap as the use
>> case - no bio overhead, dynamic resizing. However, zram being a *generic*
>> block-device has some unique cases too like hosting files on /tmp, various
>> caches under /var or any place where a compressed in-memory block device can
> Yes. I mentioned that benefit but I am not sure the reason is enough.
> What I had in mind long time ago is that zram's functionality into brd.
> So someone who want to compress contents could use it with some mount
> option to enable compression.
> By such way, many ramdisk user can turn it on easily.
> If many user begin using the brd, we can see many report about
> performance then solve brd performance s as well as zcache world-wide
> Hmm, the idea is too late?
>> So, frontswap and zram have overlapping use case of swap but are not the
> If we can insert zram's functionality into brd, maybe there is no
> reason to coexist.
I thought about this before starting with zram development but thought
adding compression (and in future, defrag) and use of custom allocator
is just too much of a hassle and thus dropped the idea. If someone is
anyhow interested in merging brd and zram I would be glad to help but I
still think that is simply not worth the effort.
next prev parent reply other threads:[~2011-02-10 1:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-07 3:26 Dan Magenheimer
2011-02-08 22:48 ` Minchan Kim
2011-02-08 23:27 ` Dan Magenheimer
2011-02-08 23:56 ` Minchan Kim
2011-02-09 16:39 ` Dan Magenheimer
2011-02-09 17:36 ` Nitin Gupta
2011-02-09 23:46 ` Minchan Kim
2011-02-10 1:17 ` Nitin Gupta [this message]
2011-02-09 23:57 ` Minchan Kim
2011-02-09 23:58 ` Minchan Kim
2011-02-15 16:53 ` Konrad Rzeszutek Wilk
2011-02-15 17:25 ` Greg KH
2011-02-15 18:18 ` Konrad Rzeszutek Wilk
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH V2 2/3] drivers/staging: zcache: host services and PAM services' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).