From: Christoph Hellwig <hch@infradead.org>
To: Petros Koutoupis <petros@petroskoutoupis.com>
Cc: linux-kernel@vger.kernel.org,
"devel@rapiddisk.org" <devel@rapiddisk.org>
Subject: Re: [PATCH] Patch to integrate RapidDisk and RapidCache RAM Drive / Caching modules into the kernel
Date: Mon, 28 Sep 2015 09:29:44 -0700 [thread overview]
Message-ID: <20150928162944.GA29562@infradead.org> (raw)
In-Reply-To: <CALMxJTyS5ARHw5NWhiPkJOh_0ys2x7cGVNdn60O6ecaUTFkq_Q@mail.gmail.com>
Hi Petros,
On Mon, Sep 28, 2015 at 09:12:13AM -0500, Petros Koutoupis wrote:
> 1. Unlike the already mainline ramdisk driver, RapidDisk is designed to be
> managed dynamically. That is, instead of configuring a fixed number of
> volumes and volume sizes as compile/boot time variables, RapidDisk will
> allow you to add, remove, and resize your RAM drive(s) at runtime. Besides,
> the built in module is designed to work with smaller sizes in mind while
> RapidDisk focuses on larger sizes that can reach to the multiple Gigabytes
> or even Terabytes. Much like the built in module, it will allocate pages as
> they are needed which allows for over provisioning (not that it is advised)
> of volume sizes.
The ramdisk driver allows to selects sizes and count at module load
load. I agree that having runtime control would be even better, but
that's best done by adding a runtime interface to the existing driver
instead of duplicating it.
> 2. The majority of RapidDisk code focuses on the use of Volatile memory.
> The support for Non-Volatile memory is a bit newer and there may be some
> overlap here with the recently integrated pmem code. The only advantage to
> having this code within RapidDisk is to provide the user with the ability
> to manage both technologies simultaneously, through a single interface.
Which really doesn't sound like a good enough reason to duplicate it.
> 3. The RapidCache component is designed around the Non-Volatile
> functionality of RapidDisk (hence the block-level Write-Through caching).
> It is also coded and optimized around the RapidDisk sizes/variables,
> out-of-box. It is worth noting that I am in the process of expanding this
> module to add deduplication support. This will leverage RapidDisk's ability
> to allocate pages only when needed and reduce the cache's memory footprint;
> making more out of less.
Still needs some code comparism to our existing two caching solutions.
I'd love to see you go ahead with the dynamic ramdisk configuration as
this is clearly a very useful feature. A caching solution that is
optimized for non-volatile memory does sound useful, but we'll still
need a patch better explaining how it actually is as useful as it might
sound.
next prev parent reply other threads:[~2015-09-28 16:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-27 17:17 [PATCH] Patch to integrate RapidDisk and RapidCache RAM Drive / Caching modules into the kernel Petros Koutoupis
2015-09-28 6:49 ` Christoph Hellwig
2015-09-28 14:50 ` Petros Koutoupis
[not found] ` <CALMxJTyS5ARHw5NWhiPkJOh_0ys2x7cGVNdn60O6ecaUTFkq_Q@mail.gmail.com>
2015-09-28 16:29 ` Christoph Hellwig [this message]
2015-09-28 16:45 ` Petros Koutoupis
2015-09-29 14:32 ` Austin S Hemmelgarn
2015-09-30 14:29 ` Petros Koutoupis
2015-09-30 15:17 ` Austin S Hemmelgarn
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=20150928162944.GA29562@infradead.org \
--to=hch@infradead.org \
--cc=devel@rapiddisk.org \
--cc=linux-kernel@vger.kernel.org \
--cc=petros@petroskoutoupis.com \
/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