From: thornber@redhat.com
To: device-mapper development <dm-devel@redhat.com>
Cc: Mike Snitzer <snitzer@redhat.com>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [dm-devel] Announcement: STEC EnhanceIO SSD caching software for Linux kernel
Date: Wed, 16 Jan 2013 10:45:47 +0000 [thread overview]
Message-ID: <20130116104546.GA3869@raspberrypi> (raw)
In-Reply-To: <C4B5704C6FEB5244B2A1BCC8CF83B86B07CE4D70CE@MYMBX.MY.STEC-INC.AD>
Hi Amit,
I'll look through EnhanceIO this week.
There are several cache solutions out there; bcache, my dm-cache and
EnhanceIO seeming to be the favourites. In suspect none of them are
without drawbacks, so I'd like to see if we can maybe work together.
I think the first thing we need to do is make it easy to compare the
performance of these impls.
I'll create a branch in my github tree with all three caches in. So
it's easy to build a kernel with them. (Mike's already combined
dm-cache and bcache and done some preliminary testing).
We've got some small test scenarios in our test suite that we run [1].
They certainly flatter dm-cache since it was developed using these.
It would be really nice if you could describe and provide scripts for
your test scenarios. I'll integrate them with the test suite, and
then I can have some confidence that I'm seeing EnhanceIO in its best
light.
The 'transparent' cache issue is a valid one, but to be honest a bit
orthogonal to cache. Integrating dm more closely with the block layer
such that a dm stack can replace any device has been discussed for
years and I know Alasdair has done some preliminary design work on
this. Perhaps we can use your requirement to bump up the priority on
this work.
On Tue, Jan 15, 2013 at 09:19:10PM +0800, Amit Kale wrote:
> 5. We have designed our writeback architecture from
> scratch. Coalescing/bunching together of metadata writes and cleanup
> is much improved after redesigning of the EnhanceIO-SSD
> interface. The DM interface would have been too restrictive for
> this. EnhanceIO uses set level locking, which improves parallelism
> of IO, particularly for writeback.
I sympathise with this; dm-cache would also like to see a higher level
view of the io, rather than being given the ios to remap one by one.
Let's start by working out how much of a benefit you've gained from
this and then go from there.
> PROPRIETARY-CONFIDENTIAL INFORMATION INCLUDED
>
> This electronic transmission, and any documents attached hereto, may
> contain confidential, proprietary and/or legally privileged
> information. The information is intended only for use by the
> recipient named above. If you received this electronic message in
> error, please notify the sender and delete the electronic
> message. Any disclosure, copying, distribution, or use of the
> contents of information received in error is strictly prohibited,
> and violators will be pursued legally.
Please do not use this signature when sending to dm-devel. If there's
proprietary information in the email you need to tell people up front
so they can choose not to read it.
- Joe
[1] https://github.com/jthornber/thinp-test-suite/tree/master/tests/cache
next prev parent reply other threads:[~2013-01-16 10:45 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-11 17:18 Announcement: STEC EnhanceIO SSD caching software for Linux kernel Amit Kale
2013-01-11 22:36 ` Marcin Slusarz
2013-01-14 21:46 ` Mike Snitzer
2013-01-15 13:19 ` Amit Kale
2013-01-16 10:45 ` thornber [this message]
2013-01-16 12:15 ` [dm-devel] " thornber
2013-01-16 16:58 ` thornber
2013-01-17 9:52 ` Amit Kale
2013-01-17 11:39 ` Kent Overstreet
2013-01-17 17:17 ` Amit Kale
2013-01-24 23:45 ` Kent Overstreet
2013-01-17 13:26 ` thornber
2013-01-17 17:53 ` Amit Kale
2013-01-17 18:36 ` Jason Warr
2013-01-18 9:08 ` Amit Kale
2013-01-18 15:56 ` Jason Warr
2013-01-18 16:11 ` thornber
2013-01-18 16:45 ` Jason Warr
2013-01-18 17:42 ` thornber
2013-01-18 17:44 ` Amit Kale
2013-01-18 18:36 ` Jason Warr
2013-01-18 21:25 ` [LSF/MM TOPIC] " Darrick J. Wong
2013-01-18 21:37 ` Mike Snitzer
2013-01-21 5:26 ` Amit Kale
2013-01-21 13:09 ` Mike Snitzer
2013-01-21 13:58 ` thornber
2013-01-22 5:00 ` Amit Kale
2013-02-04 20:33 ` Kent Overstreet
2013-01-18 16:12 ` Amit Kale
2013-01-24 23:55 ` Kent Overstreet
2013-01-17 18:50 ` thornber
2013-01-18 7:03 ` Amit Kale
2013-01-18 14:43 ` thornber
2013-01-30 12:36 ` Pavel Machek
2013-01-30 19:56 ` Amit Kale
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=20130116104546.GA3869@raspberrypi \
--to=thornber@redhat.com \
--cc=dm-devel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=snitzer@redhat.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